-
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/blob/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 ?
-
-
@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 ?
-
-
-
@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
-
-
@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 !
-
-
-
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)
-
-
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
- Save bootloader from IDE (not using Save on Send so should be all in RAM ?)
- Bootloader runs code ver 1 by eval (This was previously written to storage by bootloader)
- Code ver is running, is notified of software update so reboots to bootloader (E.enableWatchdog(1); while(1);)
- Bootloader receives code v2 via serial port, writes to Storage
- 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
- Save bootloader from IDE (not using Save on Send so should be all in RAM ?)
-
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 ?
-
-
-
I think I have another issue which is available flash space. Currently I have
FlashEEPROM start_address = 393216
Flash start_address = 397312, end_address = 430080But 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.
-
-
-
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()); }
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