Document requirement for ISR handlers to be in IRAM

[g3gg0]

Hello *,

I modified the UART based NeoPixelBus to use I²S and DMA for CPU-less transfer. (it is based on https://github.com/cnlohr/esp8266ws2812i2s)

First i tried to use Interrupts to poll for kinda vsync implementation.
But while doing that when my code wanted to save some config, SPIFFS always locked up. (no reaction, reset after a couple of minutes)
Sometimes i got an exception with PC right at the interrupt handler address which made me curious.

In the end i found out that it seems that the ROM call for flash writing does not disable (at least) SLC interrupts.
This is a no-go of course if you are rewriting flash content since the flash state machine will get corrupted on every flash access and instruction fetches return crap.

Now when i am polling SLC_RX_EOF_DES_ADDR instead of using an interrupt, everything works like a charm.

Can you confirm this behavior or am i misinterpreting things?
Wouldnt it be a good idea to disable interrupts before calling the ROM functions for flash rewriting?

BR,
Georg

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[g3gg0]

btw, i uploaded my I²S WS2812B code there:
https://github.com/g3gg0/NeoPixelBus/tree/DmaDriven

[igrr]

Hi Georg,

We can not disable all interrupts because at least WiFi interrupts have to
be serviced, otherwise MAC code will trigger an assertion.
Therefore we mask those interrupts that may cause trouble. The line is in
Esp.cpp:

static const int FLASH_INT_MASK = ((B10 << 8) | B00111010);

I think SLC interrupt number is 2, so could you add this bit to the mask
and check if this solves the issue?

You may also mark your interrupt handler with IRAM_ATTR, then it will be
placed in RAM and that may also solve the issue. You just need to make sure
it doesn't call any functions placed in flash...

On Sat, Jan 9, 2016, 05:52 g3gg0.de notifications@github.com wrote:

btw, i uploaded my I²S WS2812B code there:
https://github.com/g3gg0/NeoPixelBus/blob/UartDriven/

—
Reply to this email directly or view it on GitHub
#1388 (comment).

[g3gg0]

ah thanks. that makes pretty much sense.
is that documented somewhere or more or less some things people have to experience themselves? :)
shouldn't that code work on a whitelist basis and only allow wifi interrupts?

because if suddenly "my" interrupt handler is blocked while flash is accessed and so my function is lagging, it is definitely better by default than a crash :)

BR,
Georg

[igrr]

When I wrote that code it wasn't yet clear to me which interrupts are
necessary for WiFi stuff to run smoothly, so I disabled only the ones I was
sure about. Can certainly add SLC to the mask now.

On Sat, Jan 9, 2016, 09:30 g3gg0.de notifications@github.com wrote:

ah thanks. that makes pretty much sense.
is that documented somewhere or more or less some things people have to
experience themselves? :)
shouldn't that code work on a whitelist basis and only allow wifi
interrupts?

because if suddenly "my" interrupt handler is blocked while flash is
accessed, it is definitely
better by default than a crash :)

BR,
Georg

—
Reply to this email directly or view it on GitHub
#1388 (comment).

[g3gg0]

yeah that would be cool.
anyway, i finally implemented it without interrupts.
(if something can be done without interrupts, it's already the reason for doing so)
so this issue helped me in finding out how the I2S EOF system can be polled :)