New firmware release v1.17.3.b1



  • Hello everyone,

    This release is mainly here to fix some problems introduced by 1.17.2.b1 a few days ago.
    Here's the change log:

    • esp32: Switch off the heartbeat LED right after boot.
    • esp32/ftp/updater.c: updated function updater_write_boot_info() to write encrypted header (if flash encryption enabled)
    • esp32/ftp/updater.c: removed code which checked in ota_write() if chunks are multiple of 16 bytes
    • esp32: Use esp_timer_get_time instead of gettimeofday inside ISRs and the idle task (as recommended by Espressif). Fixes crashes caused when using time.ticks_ms() and ticks_us()
    • esp32: Only create the LTE task once. Fixes soft reset for the FiPy and GPy.
    • esp32: Correct the heartbeat behaviour during soft reset.

    Please note that that the function ticks_cpu (https://docs.pycom.io/chapter/firmwareapi/micropython/utime.html#utimetickscpu) has been changed and it now returns a value in microseconds (it's useless to return nano-seconds anyway), so it can be seen as another version of ticks_us but a lot faster. The nano-gateway example has been updated to use this function instead: https://github.com/pycom/pycom-libraries/commit/f344b5a4ac220d1c960260d80cdde07ce623bc23

    Cheers,
    Daniel



  • @daniel Hi, i have a LoPy4 with firmware 1.17.3.b1 attached to a Expansionboard v2.1A. I have a code that worked fine on SiPy, but after transfer to LoPy4 i get this error.
    Note: this error comes with or without any pins connected to the expansionboard.
    If you want the main.py, please provide me with a mail i can sent to.
    Thank you

    UPDATE: This is solved by disable wifi on boot pycom.wifi_on_boot(False)
    See topic: https://forum.pycom.io/topic/3217/lopy4-guru-meditation-error

    Guru Meditation Error: Core  0 panic'ed (InstrFetchProhibited)
    . Exception was unhandled.
    Register dump:
    PC      : 0x00000000  PS      : 0x00060630  A0      : 0x8011855d  A1      : 0x3ffbd650
    A2      : 0x00000000  A3      : 0x00000037  A4      : 0xffffffa2  A5      : 0x3fbc0af0
    A6      : 0x00000008  A7      : 0x00000000  A8      : 0x8012382c  A9      : 0x3ffbd640
    A10     : 0x3fbc0b0c  A11     : 0x00000037  A12     : 0xffffffa2  A13     : 0x3ffbd6e4
    A14     : 0x7777395d  A15     : 0x7777395d  SAR     : 0x00000010  EXCCAUSE: 0x00000014
    EXCVADDR: 0x00000000  LBEG    : 0x4009b351  LEND    : 0x4009b385  LCOUNT  : 0xffffffff
    
    Backtrace: 0x00000000:0x3ffbd650 0x4011855a:0x3ffbd670 0x40119567:0x3ffbd740 0x4012faf5:0x3ffbd760 0x40131657:0x3ffbd7b0```


  • @daniel the function wlan.isconnected() does not recognize that the access point are shutted down and the connection are falling. if i need to do something when the connection goes down i can't. I had reported the same issue in the release v1.16.0.b1.



  • @shishir Yes, I run the gateway example code from my branch, and that works fine so far. Using the gateway example code from the pycom lib may fail, because it is just a little bit too late. Here is the code I'm using:
    https://github.com/robert-hh/pycom-libraries/blob/nanogateway/examples/lorawan-nano-gateway/nanogateway.py
    That is still more a hack than a fix. But a fix would have to be deep down in the LoRa Stack and would have to schedule downlink messages there.



  • @robert-hh Is the LoRawan Nano gateway example working with OTAA ? Are you running your branch code for nanagateway?



  • @daniel +++++ It looks like this version is stable. No crash on two devices running this version since 4 days. Before, it would have failed within that time. No proof, but a strong indication.



  • @robert-hh

    not on my FiPy+PyTrack combo.

    I have to manually enable it at REPL ...

    Also, I sometimes got it to crash ... not often, but sometimes after an code-upload xor machine.reset() followed by pycom.heartrate(True) ... it crashes ...

    MicroPython v1.8.6-849-83e2f7f on 2018-03-19; FiPy with ESP32
    Type "help()" for more information.

    pycom.heartbeat(True)
    Guru Meditation Error: Core 1 panic'ed (LoadProhibited)
    . Exception was unhandled.
    Register dump:
    PC : 0x4008e53b PS : 0x00060033 A0 : 0x8008ce5d A1 : 0x3ffc1370
    A2 : 0x3ffd6f34 A3 : 0x00060023 A4 : 0x3ffc541c A5 : 0x00000001
    A6 : 0x000000fe A7 : 0x3f401f69 A8 : 0x00000000 A9 : 0x3ffd6f34
    A10 : 0x3ffd6f34 A11 : 0x00000000 A12 : 0x800de215 A13 : 0x3ffdbff0
    A14 : 0xffffffff A15 : 0x3f401f69 SAR : 0x00000003 EXCCAUSE: 0x0000001c
    EXCVADDR: 0x00000004 LBEG : 0x4009b661 LEND : 0x4009b671 LCOUNT : 0xffffffff

    Backtrace: 0x4008e53b:0x3ffc1370 0x4008ce5a:0x3ffc1390 0x4008ba0d:0x3ffc13b0 0x400874bd:0x3ffc13d0 0x40083685:0x3ffc1410 0x400e1b65:0x00000000

    ================= CORE DUMP START =================
    ...
    ...
    ================= CORE DUMP END =================



  • @combaindeft Actually the blue heartbeat is pulsing. Just the green light boot indicator is switched off immediately after boot.



  • @daniel said in New firmware release v1.17.3.b1:

    esp32: Switch off the heartbeat LED right after boot.

    Why did you by default switch of the heartbeat LED?

    It's a good thing to have on by default, as when we are trying to test new things ... and things don't work, it's good to know that we'll always have a heartbeat if the device boot up.

    Also tried to set the pycom.heartbeat_on_boot(True) .... to try to enable on our boards that it should be on by default ...

    Though it looks like even that is not working, and your default off is doing a hard overwrite.

    Atleast, if you go set default to pycom.heartbeat(False)

    allow us individually to override it with: pycom.heartbeat_on_boot(True)

    Cheers.


Log in to reply
 

Pycom on Twitter