Firmware Release v1.20.1

[dabal221]

@andreas said in Firmware Release v1.20.1:

@dabal221 said in Firmware Release v1.20.1:

Because when I update Firmware using Pycom Firmware Update I have got 1.20.0.rc13 not 1.20.1

Maybe the program will offer the newer releases after upgrading the Pycom Firmware Updater itself.

@andreas I have got 1.16.1, it is said that it is the latest stable version.

[crumble]

@dabal221

The new firmware is only visible, if you select pybytes, If yiou are asked about your bybytes ID, you can simply skip the question.

[dabal221]

@crumble said in Firmware Release v1.20.1:

@dabal221

The new firmware is only visible, if you select pybytes, If yiou are asked about your bybytes ID, you can simply skip the question.

What is the between pybytes and pybytes/legacy?

[andreas]

Dear @t0000899 and all others here,

@t0000899 said in Firmware Release v1.20.1:

Sometimes during FTP transfer there is an unhandled exception and flash memory is formatted.

Memory dump at 0x4020234c: bad00bad bad00bad bad00bad
Guru Meditation Error: Core  0 panic'ed (IllegalInstruction). Exception was unhandled.

@andreas said in Firmware Release v1.20.1:

We can confirm this after upgrading to 1.20.1 on FiPy and LoPy4 devices, with or without VARIANT=PYBYTES. We are also spuriously getting these core panics, see also https://community.hiveeyes.org/search?q=bad00bad bad00bad bad00bad.

Guru Meditation Error: Core  1 panic'ed (Cache disabled but cached memory region accessed)
Guru Meditation Error: Core  1 panic'ed (IllegalInstruction). Exception was unhandled.
Memory dump at 0x4020f958: bad00bad bad00bad bad00bad

We have been working on mitigating these issues, so if you feel lucky, you might want to try one of our custom builds published to [1]. More background about this is available through [2].

If we are lucky together, this will improve the stability significantly. If you will be still receiving the core dumps, I will be happy if you would share its content with us. Please just don't paste it into the comment itself but put it into a file which you will be able to upload by dragging it into the text area.

Please be aware that when upgrading from a lower firmware version to the current 1.20.1.r1 development release these builds are based upon, you will have to erase your device completely before flashing in order to keep things straight as outlined within this topic already. Hint: Use a command like pycom-fwtool-cli --port /dev/ttyUSB0 erase_all, see also [3].

Please also be aware that this procedure will also erase the LoRa MAC stored on the device. @robert-hh thankfully outlined the procedure to restore it appropriately:

• If you still know the value the LoraMac had before, then you can follow the procedure explained at https://forum.pycom.io/topic/1272/lora-mac-ffffffffffffffff/21.
• If you do not know it, you will have to use the Pycom updater to restore it:
  • First, use the Pycom updater (GUI version) to install a recent image (like pybytes 1.20.1) from the Internet. You do not have to use it, the installation process itself already restores both the LoRa MAC and the Sigfox ID.
  • Then, use the Pycom updater to flash the custom image. Do not erase the flash in between.

As it turned out to gain more robustness for others already [4,5], we will be happy to learn if this happens to you as well.

Have fun!

With kind regards,
Andreas.

P.S.: For all people who want to go with Pybytes, we just published builds using VARIANT=PYBYTES at [6]. When going that way, you should probably save the pybytes_config.json before invoking the erase_all procedure and restore it to the device afterwards.

P.P.S.: All these builds use the LittleFS filesystem to prevent filesystem corruption which works for us very well.

[1a] https://packages.hiveeyes.org/hiveeyes/foss/pycom/vanilla/LoPy4-1.20.1.r1-0.6.0-vanilla-dragonfly.tar.gz
[1b] https://packages.hiveeyes.org/hiveeyes/foss/pycom/vanilla/FiPy-1.20.1.r1-0.6.0-vanilla-dragonfly.tar.gz
[2] https://community.hiveeyes.org/t/investigating-random-core-panics-on-pycom-esp32-devices/2480
[3] https://community.hiveeyes.org/t/installing-the-recent-pycom-firmware-1-20-1-r1-requires-erasing-the-flash-memory-completely/2688
[4] https://community.hiveeyes.org/t/testing-the-custom-dragonfly-builds-on-pycom-devices/2746
[5] https://github.com/pycom/pycom-micropython-sigfox/issues/361#issuecomment-553399627
[6] https://packages.hiveeyes.org/hiveeyes/foss/pycom/pybytes/

[bilou7]

@iwahdan
Hello,
I am using Fipy and Lopy4 device which are getting data from a Ruuvitag by BLE connection. Since I have updated the firmware 1.20.1, pycom devices doesn't get any value from the ruuvi. Do you know if there is an issue with BLE connection with the new firmware ?

[serafimsaudade]

I'm trying to compile the pycom-micropython to use only one core.
I compile the idf libs, I make menuconfig and select "component config->FreeRTOS-> Run FreeRTOS only on first core". the compilation runs ok.
I move the libs to the pycom-micropython and compile the firmware, and program the wipy with no problems.
After the programming completes, the pycom enter into a loop when loading the bootloader and don't go to the python shell.

D (695) bootloader_flash: mmu set paddr=001e0000 count=1 size=20 src_addr=1ebab0 src_addr_aligned=1e0000
D (704) bootloader_flash: mmu set paddr=001e0000 count=1 size=20 src_addr=1ebab0 src_addr_aligned=1e0000
pycom-esp-idf/components/freertos/tasks.c:685 (xTaskCreateStaticPinnedToCore)- assert failed!
abort() was called at PC 0x4009097b on core 0

Backtrace: 0x40092c0f:0x3ffbab00 0x40092e15:0x3ffbab20 0x4009097b:0x3ffbab40 0x400de0b5:0x3ffbab80 0x400d2411:0x3ffbabb0

If I disable Run FreeRTOS only on first core. The pycom boots.

D (706) bootloader_flash: mmu set paddr=001e0000 count=1 size=20 src_addr=1ed800 src_addr_aligned=1e0000
Pycom MicroPython 1.20.1.r1 [4c809f4e-dirty] on 2019-11-21; LoPy4 with ESP32
Type "help()" for more information.
>>>

[regiskiwi]

@andreas I have been having the "Cache disabled but cached memory region accessed" exception in my custom (LOPY) build but it is hard to reproduce. When this happens in 1.20.r1 the CPU loops in the panic handler and hangs up there and only a POWEROFF reset will reboot the device ( WTG does not work). I made some minor changes in panic.c and got it to reboot if the exception happens. (the loop is caused by a call to rtc_wdt_set_time()).

That's all good but I need to find what could be causing this exception and I wonder if you can help me there:
In LoRaMAC.c there are radio 5 handlers defined but only one of them (OnRadioTxDone) is using the IRAM_ATTR attribute. It seems that all 5 of those handlers are called within an interrupt context so I think that they should be located in IRAM too. Any reason why they are not?

The handlers are:
RadioEvents.TxDone = OnRadioTxDone;
RadioEvents.RxDone = OnRadioRxDone;
RadioEvents.RxError = OnRadioRxError;
RadioEvents.TxTimeout = OnRadioTxTimeout;
RadioEvents.RxTimeout = OnRadioRxTimeout;

Thanks a lot.
Regis

[andreas]

Dear @regiskiwi,

@regiskiwi said in Firmware Release v1.20.1:

I have been having the "Cache disabled but cached memory region accessed" exception in my custom (LOPY) build but it is hard to reproduce.

I hear you. We experienced the same and went through all the jazz outlined within [1] to produce some more stable builds. However, I am sorry that we haven't been able to upstream the changes appropriately. As we recognized folks of Pycom have been pretty busy on their World Tour, I will try again to get through to @Xykon next week.

If you can get by using unmodified builds in any way, you are welcome to try our Dragonfly builds in the meanwhile [2].

As I am not using LoRa yet, I can't tell about any possible issues with the OnRadio* event handlers regarding IRAM.

With kind regards,
Andreas.

[1] https://community.hiveeyes.org/t/investigating-random-core-panics-on-pycom-esp32-devices/2480
[2] https://community.hiveeyes.org/t/testing-the-custom-dragonfly-builds-on-pycom-devices/2746

[robert-hh]

@regiskiwi It is quite a while ago since I dug my way through the Lora stack. I had seen this IRAM/Not IRAM setting. But at that time it seemed plausible for me due to timing constraints. After TxDone, the device has to meet a very narrow time window for possible downlink messages. With caching needed that window may have been hard to hit. For the other events, timing is less critical. So I wonder more why caching is disabled. Did you do that intentionally in your code? Without caching, the firmware is hardly usable.
Did you try to add the IRAM attribute to the other handlers?

P.S.: I made also the experience that the internal WDT is not effective.

[regiskiwi]

@andreas said in Firmware Release v1.20.1:

We experienced the same and went through all the jazz outlined within [1] to produce some m

Thanks Andreas, Robert We have made modifications to the LOPY build so I can not easily use the vanilla one provided. I am looking forward to see the changes you made in github. In the meantime, I am using the latest toolchain from expressif (90) and mfix-esp32-psram-cache-dupldst flag. I have also added the attribute IRAM to the OnRadioRxError, OnRadioTxTimeout, OnRadioRxTimeout interrupt handlers and in a few functions called by OnRadioTxDone (I am using a class C device). The difficult bit is OnRadioRxDone. This handler logic is long and I think it should really need to be moved to a separate thread to keep the ISR logic small and fast. what do you think?
I think I am hitting this caching issue a lot because we do make use of NVS (config variables)
thanks

[regiskiwi]

@robert-hh Thanks Robert. As far as I understand, cache is disabled by the CPU when SPI access is undertaken (https://docs.espressif.com/projects/esp-idf/en/latest/api-guides/fatal-errors.html#cache-disabled-but-cached-memory-region-accessed) . If an ESP_INTR_FLAG_IRAM interrupt triggers during that time and it tries to access cache it will raise this exception. As far as I can see OnRxDone is called by SX1272RadioFlagsIrq and this timer interrupt is in IRAM so likely to be active during flash access.
Thanks
Regis

[regiskiwi]

@robert-hh Just a note, the timer interrupt seems located in IRAM :
timer_isr_register(TIMER_GROUP_0, TIMER_1, HAL_TimerCallback, NULL, ESP_INTR_FLAG_IRAM, NULL);

[robert-hh]

@regiskiwi Are you using a LoPy1 w/o SPIRAM or Lopy4 with SPIRAM?

[regiskiwi]

@robert-hh I am using a L01 (4MB SPIRAM + 8MB Flash)

[goldfishalpha]

This post is deleted!