Firmware Release v1.20.1

[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!