New firmware release v1.17.3.b1
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
@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.
UPDATE: This is solved by disable wifi on boot
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.
robert-hh last edited by
@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:
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?
robert-hh last edited by 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 last edited by
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.
Guru Meditation Error: Core 1 panic'ed (LoadProhibited)
. Exception was unhandled.
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 last edited by
@combaindeft Actually the blue heartbeat is pulsing. Just the green light boot indicator is switched off immediately after boot.
combaindeft last edited by
@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)