Firmware Release v1.20.1

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