RAK8212: Issue with save() freezing up the system

I am currently playing around with a RAK8212 and wrote a module to interface with the Quectel BG96 that is aimed at Narrowband IoT (NB-IoT) communication. I tried my best, but I am a newbie and possibly the code quality is bad ...

But the actual issue is that when I call "save();" the RAK8212 freezes up and I need to press the reset button to get it back into live.

I would appreciate some hints what I am doing wrong or how the issue can be solved.

I have placed the code into a github repository at https://github.com/wklenk/rak8212-espruino-nb-iot

Output:

>
 ____                 _
|  __|___ ___ ___ _ _|_|___ ___
|  __|_ -| . |  _| | | |   | . |
|____|___|  _|_| |___|_|_|_|___|
         |_| espruino.com
 1v99 (c) 2018 G.Williams
Espruino is Open Source. Our work is supported
only by sales of official boards and donations:
http://espruino.com/Donate
>Setting up external hardware. Please wait ...
BME280 wiring set up.
Quectel BG96 wiring set up.
>save();
=undefined
Compacting Flash...
Calculating Size...

Are you connecting through Bluetooth, or USB Serial?

Can you also maybe try removing the setupExternalHardware() call that's in the global scope? With it, it gets called when you upload - but then when you save you save the current state (including whatever state of initialisation it was at), but then setupExternalHardware() gets called again from onInit() - it's possible that is causing you problems.

Hi,

I am connecting through Bluetooth.
I removed setupExternalHardware() from onInit(), but it still freezes.

Then I started with a tiny module BG96NB1.js, adding more and more lines of code step by step.
I ended up in just adding lines like console.out("XXXXXXXXXXXXXXXXXXX") to find out the module size that still worked, while adding just one more line of console.out made save() freeze again.

The largest size of the overall program I could see was 12261 (0x2FE5) bytes.

Setting up external hardware. Please wait ...
BME280 wiring set up.
Quectel BG96 wiring set up.
save();
=undefined
Compacting Flash...
Calculating Size...
Writing..
Compressed 40000 bytes to 12261
Running onInit()...

This makes me assume that there must be some kind of limit at about 12288 (0x3000) bytes.
Could this actually be true?
I can't believe why the application should fit into RAM, but not into flash.

process.memory();
={ free: 1620, usage: 880, total: 2500, history: 421, gc: 0, gctime: 5.09643554687, "stackEndAddress": 536927056, flash_start: 0, "flash_binary_end": 382804, "flash_code_start": 471040,
flash_length: 524288 }

Found this in https://github.com/espruino/Espruino/blob/master/boards/RAK8212.py :

chip = {
  'part' : "NRF52832",
  'family' : "NRF52",
  'package' : "QFN48",
  'ram' : 64,
  'flash' : 512,
  'speed' : 64,
  'usart' : 3,
  'spi' : 3,
  'i2c' : 2,
  'adc' : 1,
  'dac' : 0,
  'saved_code' : {
    'address' : ((118 - 3) * 4096), # Bootloader takes pages 120-127, FS takes 118-119
    'page_size' : 4096,
    'pages' : 3,
    'flash_available' : 512 - ((31 + 8 + 1 + 3)*4) # Softdevice uses 31 pages of flash, bootloader 8, FS 1, code 3. Each page is 4 kb.
  },
};

Does this mean 3 * 4096 byte only for saved code?
Compared with the Nordic NRF52832 (https://github.com/espruino/Espruino/blob/master/boards/NRF52832DK.py) why does this have 10 pages a 4096 byte for saved code?

I glanced over the module code... and even though I agree with the approach of using Promises to get over the asynchronous needs, you might resort to something much less elegant...

One of the main reasons is that Espruino runs off of the source code. The interpreter has to have a reasonable expression in JS to get to work. The highly elegant and correct solution with so many Promises in one single expression could render just to much for Espruino to deal with. I may be completely wrong, but I would use a simple sequencer / tasker / state machine to do that. I built something similar to overcome asynchronous calls in a sequence with retry support (yes, retry support can also be implemented in Promises, as I just very recently came across in the forum in order to break out/fail/reject after x timed retries, but again, it is within Promises and may pull in even more such):

• sequencing - configure, require(), initializing w/ onInit() and save() ...and bind()
  
• Tasker - Task synchronizer - kind of a 'purposed' Promise
  
  

I'm sure you try to save the code before even somethings started to run, correct?

I'm sure you try to save the code before even somethings started to run, correct?

Thanks for the idea with the state machine. In fact, in the end the code has to run unsupervised and therefore it has to be more robust and resilient.

The idea is to build a basic data logger that runs directly from flash when the device is powered on. The data should be sent using protocols like MQTT, CoAP or HTTP.

Regarding robustness: are you considering setTimeout()/setInterval() of monitor tasks that worst case hit the reset button if something got hanging? ...or even more independent, like an extra watchdog mc - simple 8 bit STM8 or alike that would monitor? ...and they would monitor each other?

Thanks for looking into this - you're right. I'm not sure how the RAK boards ended up with only 12k reserved for saved code. I've just updated this to 40k like the other nRF52 devices.

There is some compression support in Espruino so 12k isn't as dire as you might think, but it's still easy to hit (although hopefully when you're using a built-in module for BG96 that'd reduce your code size even further).

The fact that it actually crashes when trying to save too much is bad news though. I'll take a look at that - it should just report that the saved code is too big.

Ok, just checked up on this - turns out it's a bug in the Storage code that makes it crash if you try and write a bigger file than will fit in memory (but only when Storage is empty!).

It's now fixed, so cutting-edge builds should be working fine.

Hello Gordon,

these are really good news :)
For RAK8212 I can see the cutting-edge build

bootloader_espruino_1v99_RAK8212.hex

But shouldn't there be another hex file that contains the complete Espruino firmware?
I can't wait to try it out ...

Best regards,
Wolfgang

Argh - sorry. I made some code changes late yesterday and forgot to add a few new files. If you wait a few seconds it should be fixed now.

Gordon, I had hoped you'd pick up on the problem! It now builds for me.

Great!
You made it :)

Thanks a lot for all the support.

I also met the same problem by using the latest espruino_2v01_RAK8212.hex (3 April,2019), could you please share with me how to solve it?

I didn't solve it! Gordon did.

Hi Gordon, can you please tell us how to solve it?

anyone can help ?

You mean 'save()' is hanging for you? It's possible it's the code you uploaded.

Can you try a 'cutting edge' build, just in case? http://www.espruino.com/Download#RAK8212

not hanging when doing " save", it's hanging when new restarting.

It might just mean that you uploaded code that caused it to hang?

Can you get it working by shorting TILT_DOUT to 3.3v and restarting? That'll make it not load any saved code on boot.

If that works then try uploading and saving some really simple code (like turning an output on and off) and see if that works.

it worked when we used the really simple code, when we tested by using https://github.com/wklenk/rak8212-espruino-nb-iot/blob/master/upload-ssl-certs-to-bg96.js.

it can work after modifying a little for Singapore Cat-M1. even worked fine after doing "save", but it hanged when we restarted the board by turning off and turn on power

after re-flashing your latest 'cutting edge' build( 8/4/2019), it seems be improved, but still not reliable. sometime it hanged, sometime the codes lost . the board can't be restarted by shorting TILT_DOUT to 3.3v , also it can't be restarted by shorting P21RESET to 3.3v or GND.

it can be restarted by P21RESET to GND.

the board can't be restarted by shorting TILT_DOUT to 3.3

That's intentional - you need to restart while shorting TILT_DOUT to 3.3v to boot without loading code.

it worked when we used the really simple code

Ok, so there's some issue with your code by the sound of it. I'd suggest:

• Reset the board
  
• Connect via Bluetooth
  
• Upload your code and save
  
• Type load() on the left-hand side - this will mimic a power on reset. It might be that you see some errors reported.
  

there is no any error when doing "Load",

load();
=undefined
Loading 11308 bytes from flash...
Running onInit()...
onInit...
Start Testing...
Connecting Cellular Modem ...
Cellular Modem connected.
BME280 wiring set up.
["AT&F0\r\n"
] "AT&F0\r\r\nOK\r\n"
["ATE0\r\n"
] "ATE0\r\r"
] "\nOK\r\n"
.......

after cold reboot , we can't see any error message most of time, sometimes we can see the messages as below

"\r\nR"
] "DY\r\n"
] "\r\nR"
] "DY\r\n"
] "\r\nR"
] "DY\r\n"
] "\r\nR"
] "DY\r\n"
] "\r\nR"
] "DY\r\n"

if we do "Load" this time , then everything worked fine.