Skip to content

Document requirement for ISR handlers to be in IRAM #1388

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
g3gg0 opened this issue Jan 8, 2016 · 7 comments
Closed

Document requirement for ISR handlers to be in IRAM #1388

g3gg0 opened this issue Jan 8, 2016 · 7 comments

Comments

@g3gg0
Copy link

g3gg0 commented Jan 8, 2016

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
Copy link
Author

g3gg0 commented Jan 8, 2016

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

@igrr
Copy link
Member

igrr commented Jan 8, 2016

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 [email protected] 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
Copy link
Author

g3gg0 commented Jan 9, 2016

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
Copy link
Member

igrr commented Jan 9, 2016

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 [email protected] 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
Copy link
Author

g3gg0 commented Jan 9, 2016

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 :)

@igrr
Copy link
Member

igrr commented Mar 11, 2016

Adding bit 2 (which is shared between SPI and I2S) to the mask causes the chip to lock up. So I'm not sure that masking I2S interrupts is possible while accessing flash.

@g3gg0
Copy link
Author

g3gg0 commented Mar 11, 2016

yeah, so putting a comment that explains that interrupt handlers have to be put into RAM is the best solution i guess.

@igrr igrr modified the milestones: 2.2.0, 2.3.0 Apr 18, 2016
@igrr igrr changed the title SPIFFS interrupt lock missing? Document requirement for ISR handlers to be in IRAM Jun 3, 2016
@igrr igrr modified the milestones: 2.3.0, 2.4.0 Jun 23, 2016
@igrr igrr removed this from the 2.3.0 milestone Jun 23, 2016
devyte added a commit that referenced this issue Dec 12, 2017
Added section Other causes for crashes with ISR, Async callbacks, memory guidelines, stack.
Fixes #1388 .
devyte added a commit that referenced this issue Dec 28, 2017
* Update a02-my-esp-crashes.rst

Added section Other causes for crashes with ISR, Async callbacks, memory guidelines, stack.
Fixes #1388 .

* Update a02-my-esp-crashes.rst

Minor typos and text fixes

* Update a02-my-esp-crashes.rst

Fixed stack size typo
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants