Aside from SPI I also had I2C interrupts (via transaction complete) and a single GPIO interrupt.PeterR wrote: ↑Fri Nov 09, 2018 10:12 amThanks, yes your report seems very similar but my application still fails when SPI activity was pinned to core 0 (achieved 30 min which is longest run so far).
I will go back & ensure that the SPI bus & devices are created from core 0.
I also use Ethernet RMII. There are some broadcasts on my test network and also my application logs via UDP - there will be regular Ethernet interrupts and DMA during normal testing.
With Ethernet removed & all SPI transaction on core 0 I achieved 18 hrs last night & still running.
Did you have any other interrupt and/or DMA activity in your test program?
HSPI on core 0, VSPI on core 1, No Ethernet, Main Application - seems to work
HSPI on core 0, VSPI on core 0, Ethernet, Main application - seems to work
HSPI on core 0, VSPI on core 1, Ethernet, Main application, fails quickly
HSPI on core 0, VSPI on core 1, Ethernet, MWE, seems to work
Thinking that cache may be related I created a large IRAM_ATTR array and tried to read from it.
I get '0x40089a1c: _xt_nmi at ??:?'
How would I use cache & so flush the program out of cache & simulate 'real life'?
EDIT: Fixed. Needed to use 32 bit access.