Interrupts and sdk func

[SpenZerX]

Hello,

is it allowed to use sdk functions (os_malloc, strcpy) in interrupts (GPIO)?
Can subroutines called from interrupt get ICACHE_FLASH_ATTR?

Or may this be the cause of random watchdog resets?

[dkinzer]

is it allowed to use sdk functions (os_malloc, strcpy) in interrupts (GPIO)?

In an ISR, it is not allowed to call a function, either directly or indirectly, that resides in .irom0.text. If you are unsure where a function is located, consult the .sym file (which can be generated from the .elf file by "xtensa-lx106-elf-gcc-nm -n").

[SpenZerX]

So what is the best technique to pass event Information from IRQ immediately to a processing / main task?
(Without stopping main task with polling)

Set up a poll timer (1 millisecound timer) , which can use SDK-Functions?

[joostn]

In your user_init, register a task queue and a task handler:
system_os_task(..);

In your interrupt handler, say it's an UART RX interrupt:
store the received data in a buffer and signal the task queue by calling:
system_os_post(..);

system_os_post will cause the task handler you registered in system_os_task to be called 'very soon', but outside the interrupt context. In the task handler you do any lengthy processing. While your task handler is running, new interrupts may occur. The interrupt handler should be kept as short as possible. Even if it would be safe to call malloc, doing this in a ISR is bad practise. Instead pre-allocate the necessary buffer space in your user_init.

In a well designed system polling is never necessary.

[SpenZerX]

system_os_post(..) was my first thought, too. Thanks.

But it is an SDK Function that may be also cached from rom. I will give it a try.

[dkinzer]

But it is an SDK Function that may be also cached from rom. I will give it a try.

It isn't. And, by the way, it isn't necessary to just blindly try something. As I mentioned you can generate a .sym file and confirm with certainty whether a particular function (SDK or otherwise) is in .irom0.text. The .sym file excerpt below, from one of my applications, clearly shows that system_os_post is not in .irom0.text. Any function listed between _irom0_text_start and _irom0_text_end is cached. If a function is listed elsewhere, it isn't cached.

Code: Select all

...
40100220 T pvPortMalloc
401008f0 T system_get_time
4010090c T system_os_post
...
40211000 A _irom0_text_start
40211008 T post_init
40211034 T zb_mainTaskAddr
40211034 T zf_Main
...
4023b70c A _irom0_text_end

It should be noted, however, that a non-cached function may call a cached function. One would have to generate a .lss file and examine the code to be certain. Even then, the code for the internal ROM functions (those listed in eagle.rom.addr.v6.ld) won't be listed. It is probably a safe assumption that the internal ROM functions don't invoke irom0 functions unless a callback is involved.

[joostn]

system_os_post is safe to call from an interrupt. Otherwise it would have no purpose..

[eriksl]

Although I completely agree with the approach described by Don Kinzer, I must say that it's not per sé illegal to call another function or use code not in iram. Just be very careful what you do. The problem with calling other functions, especially in non-iram, that they often take too long to complete. Interrupt service routines should be a couple of lines at max to be safe always. Interrupt routines that take long to complete is simply asking for trouble. Golden rule: use background tasks to do the work, indeed. And that's not only on the ESP8266, that's on every platform.

[joostn]

You can mostly get away with it. But the problem is if if an interrupt occurs while a flash write is in progress, and that interrupt will call code in flash, then the ESP will crash. The SDK code will write to flash the access point settings and (presumably?) RF calibration data. You can not be sure when exactly this happens.