RAK8212: Issue with save() freezing up the system

Posted on
  • 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-esprui­no-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/blo­b/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/blo­b/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):

    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.

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

RAK8212: Issue with save() freezing up the system

Posted by Avatar for wklenk @wklenk

Actions