New firmware release v1.17.3.b1

[daniel]

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

[bjsi9]

@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```

[p3pp3d0m]

@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.

[robert-hh]

@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.

[shishir]

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

[robert-hh]

@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.

[combaindeft]

@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 =================

[robert-hh]

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

[combaindeft]

@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.