Search results for:

Excellent news, I have loaded the latest hex and my app is running. The only thing I am noticing at the moment is that I am getting occasional UART_OVERFLOW errors with serial to the BG96 and so commands are getting corrupted

I needed to figure out how to create a custom build yesterday (for the first time) and noticed it was down also. I needed to remove/add some libs to MDBT42Q.

But what I found is that it is real easy to do these builds, @Gordon has made the process real easy to make the build process work at https://github.com/espruino/Espruino/blo­b/master/README_Building.md

Took me hour or so to create a custom MDBT42Q build without any prior knowledge - I just used the Ubuntu you can fire up in Windows.

Just for anyone who had not had a go at this.

@Gordon but I am now having an issue where I am getting BLE error 0x6 and BLE error 0x8 with setScan() ? This is the same code I am running fine on nrf52832 hardware. Any thoughts ?

OK it looks like my BG96 got shipped to me still in a factory test mode - so once I got out of that things are working again !

@Gordon I am having problems with the BG96 not accepting some AT commands eg AT+CFUN=1 and AT+CFUN? returns 5 which is not even a documented state. It seems like it is in some non-active state.

I wondered if it is in airplane mode (LTE_WDISABLE pin) - had a quick look but that seemed OK. Did you manage to check if the BG96 was actually working ? I am just not sure if my BG96 has an issue or whether some of the signals from nrf are not in the correct state ?

nrf52840 has so much flash, would be good to have more allocated to Storage region, as that would be good place to store remote software updates

Is the flash_code_start in the correct place at 966656 ?

On the MDBT42 I use the space between flash_binary_end and flash_code_start for the "flash" module for word level logging. But I dont want to end up going up into where the Storage module is putting things ?

@Gordon thanks so much ! I have it up and running. The number of variables needs bumping up for extended RAM, will let you know what else I find

Hi @Gordon just another little check in for an ETA update ?

I see that the nrf52840 has 2x UART, will those both be available ? Will be really useful to be able to debug BLE comms whie one serial port is allocated to the BG96

Thanks

Its ok right now as I also have a rak8212 which I am currently developing on - but having access to more flash/ram will help with new features I need to add. Will the Flash module have access to more space ? We currently use that for our logging data.

@Gordon any update on when you might get to having a look at this build ? Realise you are juggling a lot, just interested in an updated ETA

I have a rak5010 sitting here ready to go !

All good ! My son is enjoying his Bangle.js - turned up 2 days before his birthday which was fantastic

Any update on the timeline for this ? The RAK8212 does not seem to be able to be ordered at the moment

It seemed to be an issue while running bootloader and on saving a second, new copy of the code before deleting the original. It did work if i deleted original code first.

I have not got back to further testing because in the meantime some external changes have meant i need to put a lot more code into the mdbt42. So i am just hoping when i am done that the bootloader plus code save will still work fine. I will let you know when I get there.

A dont reorganize flag may end up being useful

If I can achieve running at boot my bootloader, using Storage to save a new remotely loaded version to flash, then eval from flash then I should be OK as there will be plenty of RAM available.

But if in the above scenario I will run into the issue of the code getting shuffled and so cannot run, then I will have a problem. I don't need to store a second copy of code. If my bootloader detects a new version from remote source, it can delete the current version from Storage (if that helps)

Do you know when you might have a nRF52840 module available ? My project scope has changed and things are starting to get tight inside the MDBT42Q !

So could the compact/rearrange occur during the first eval ? I am not sure if this is the problem, as even if I reboot and try to eval the code later it still fails. So what I was doing originally was

1. Save bootloader from IDE (not using Save on Send so should be all in RAM ?)
   
2. Bootloader runs code ver 1 by eval (This was previously written to storage by bootloader)
   
3. Code ver is running, is notified of software update so reboots to bootloader (E.enableWatchdog(1); while(1);)
   
4. Bootloader receives code v2 via serial port, writes to Storage
   
5. Bootloader eval code v2 but fails due to code errors. Even if I reboot it still fails.
   
   

If I delete code v1 before writing v2 to Storage, it works. Not sure if that shows something I am missing.

I will try your suggestion of eval to RAM as well

OK so I have my MEDBT42 bootloader up and running now. It loads new code in from another module via the serial port, saves to Storage and then eval.

What I started with was keeping a copy of the previous working copy also, but I found then on writing the second, new copy of code on eval the code was corrupt and would not run. The code size is 10.5kB.

I am also saving the bootloader code from the IDE using 'save on send' and I have also observed the bootloader code getting corrupted when saving both copies of main code.

I would not have thought that I am running out of space with my bootloader of 3k and 2x 10.5kb there would be a size issue that would cause the corruption ? Any thoughts ?

What do you mean by your earlier comment of running from flash that 'it will be pretty efficient' ?

What are the downsides to running from flash vs loading to RAM ? (Apart from the deletion issue you pointed out)

OK sounds good ! So the Storage lib is just using from flash_code_start onwards ? And so it wont clash with the Flash lib I have set to work between 397312 and 430080

I think I have another issue which is available flash space. Currently I have
FlashEEPROM start_address = 393216
Flash start_address = 397312, end_address = 430080

But process.memory().flash_code_start is reported as 442368. So I only have 12kb of space left which is not going to be enough for storing 2 copies of code. So I may have to rethink my strategy a bit if I cant get a little more free flash space.

Is there a way to alter .flash_code_start ? As the only initially saved() code would be my small bootloader

On the MDBT42 currently I use Flash (for a circular logging buffer where some bytes are written twice before erase) and FlashEEPROM for storing a couple of params. I make sure they don't overlap by doing the following:

flashEEPROM = new (require("FlashEEPROM"))();
flashEEPROM.endAddr = flashEEPROM.addr+PAGE_SIZE;
  
flash = require("Flash");
logStartAddress = flashEEPROM.endAddr;
logEndAddress = logStartAddress + NUM_LOG_PAGES*PAGE_SIZE;

I am interested in swapping out flashEEPROM for the new Storage Library as want to store downloaded code to run and it seems a nice way to handle it. Can I get it to run alongside the Flash library ? If not I will just use the Flash lib to store the code.

How far away are you from having the mdbt42q modules for sale ? We need some more !

Oh i did not think to check that. I just assumed the external pads were free. Easy to swap over.

I have attached a SI7055 temperature sensor to a Ruuvitag as I need 2x temperature sensors for an application. My simple test app is below . If I call readBmpTemp() I get a correct temperature. If I then call read7055Temp() - the first time I get an I2C arbitration error and then the second call works. If I switch back to readBmpTemp() the first reading is incorrect etc

Is there something I have setup wrong ?

var i2c;
var Ruuvitag;

function onInit() {
  Ruuvitag = require("Ruuvitag");
  Ruuvitag.setEnvOn(true);
  
  i2c = new I2C();
  i2c.setup({ scl : D28, sda: D29 });
}

function read7055Temp() {
  i2c.writeTo(0x40, [0xf3,0x40,0x40,0x40]);
  
  setTimeout(function() {
    var rawTemp = i2c.readFrom(0x40, 2);
    var val = (rawTemp[0] << 8) + rawTemp[1];
    var temp = (175.72*val) / 65536 - 46.85;
    console.log(temp);
  }, 10);
}

function readBmpTemp() {
  console.log(Ruuvitag.getEnvData());
}