ESP8266 Community Forum

- Mon Jan 14, 2019 8:25 am #80055

Why do isr functions need to be in RAM? See here for some info : https://github.com/SuperHouse/esp-open-rtos/issues/559

I don't think I ever read a definitive explanation, but my gut feeling tells me that if the isr is in flash then flash has to be read which itself causes interrupts (or needs interrupt servicing), but at that point NMI has disabled interrupt servicing so the esp8266 just hangs and wdt ensues.

I bet rudy knows the answer?!

As to the definitive answer for when do RTOS/SDK callbacks need to be in RAM? Well the link above seems to indicate some cases do and some do not need it. So treat with caution.

Great!
Thank you for the explanation!
I needed to understand this to know when to use it.

See ... I have two situations and maybe this will help me.
I want your opinion!

I use a timer interrupt in my application to count the times. This interruption (every second) is not on the ram. But it never gave me trouble, should I put her on the ram?

The second situation:
In my product I have the possibility to use modbus communication between some equipment that send me sensor data. It turns out that when I have some equipment connected and picking up data my equipment sometimes times out and resets. These resets sometimes do not happen, but sometimes they happen 5 a day!
My equipment le data from these other equipment, about 5 times per minute.
The errors that occur are:
WDT Hardware
WDT Software
Sometimes very rare: Fatal Exception 29 (there have already been others such as 4 and 3, but 29 is more common)

I do not know what can be, I have already reviewed and can not find any errors. I follow the memory and it does not burst.
Incredible, that the equipment communicates 5 times per second and the error happens in the maximum 5 or 8 times in the day. Resetting my equipment.

I do not know if there's any way the function question is not on the ram. But that came to mind.

- Mon Jan 14, 2019 8:27 am #80056

I have finally started the ball rolling with my tracing tool and posted a topic with the documentation so far

viewtopic.php?f=11&t=19046

WOW!
It came out fast!
Nice!
I'll take it easy, try to understand. I know it's very complex. I need to understand, because it is an exceptional tool!
Thank you for remembering and sharing !!!

- Mon Jan 14, 2019 10:10 am #80058 These things are never easy I'm afraid. I have worked in real time systems for 33 years now, and it is a mixture of 'gut feeling' and knowledge of the particular microprocessor/hardware. Failing just a few times a day with many interru0ts per second is not uncommon.

Generally you would get a stack overflow rather than a wdt reset on ram exhaustion (though not always).

Definitely put the timer callback in RAM, the need to do this is in the espressif documentation. Any function that the callback calls also needs to be in RAM. Do the same for all ISRs.

Any system API that requires a user callback function most likely gets triggered on an interrupt, so you need to check the docs and put the necessary functions in RAM also.

Unfortunately this kind of problem can take lots of time to find and fix.

Another thing to add is your own watchdog - this will allow you to find where your code is hanging (assuming it is your code). It can detect a timeout and causea stack dump which will allow you to do a stack trace analysis of the call tree - it may possibly help. There are some examples/tutorials on this, but I cannot seem to find them. I will look again later and post any lins I find.

Also, you should not have any delay/sleep calls in anything which can hold up interrupt processing. Delay/sleep and any I/O inside an isr is generally forbidden.

Do you have wifi enabled? Sometimes it is just that the user code is taking a long time doing something and it upsets the wifi and then a wdt occurs.

EDIT : Look at this video on creating your own watchdog : https://www.youtube.com/watch?v=D_7ciW_ ... u0&index=6

I use this kind of thing to trap software faults : I set this 'soft' watchdog timeout lower than the esp's hardware time and then I can report any timeout before the esp does a wdt. I set it to 0.5 seconds.

- Tue Jan 15, 2019 11:36 am #80071 I have been thinking about your problem some more...

I had a look at Espressif non-os sdk api reference and there are notes about when to use IRAM_ATTR tagged functions : As we already said, all ISRs must be tagged this way. In addition hardware timer callbacks. There is no reference to software timers (os_timer) so perhaps this is unnecessary. However I have a note in my own code that this is needed so it's up to you really. I wouldn't risk a problem and just make os_timer callbacks RAM resident : Of course, you may also be using a 3rd party library which hides this from you, so you would have to check these libraries as well.

I am assuming that you are using the non-os sdk. Am I correct?

Are you using the ESP8266 Arduino Core with the sdk, as many people do? I assume you are. If you are then I would seriously question why you have chosen this for something which is a commercial product... As follows:

Yes, the Arduino Core is simple/straight forward to use and it means you have many 3rd party libraries (that are primarily written for Arduino) available, however you are using a 'hobbyist' platform for a commercial product and that needs to be understood by your senior managers etc in your company in order for them to assess the risks, both now and in the future. It does not have the same implied support/assurance that using the official Espressif platform does. Assuming Espressif would give support/assurance that is, which I have no experience of.

Furthermore, what if you wanted to port your product to the esp32? Big problem! The esp32 uses the 'ESP-IDF' which is very different, and is at its core the FreeRTOS operating system. In essence the same as if you used the esp8266 os sdk and not the non-os sdk (excuse the emount of nons and nots in that sentence!).

The same is true for other microprocessors such as ARM (STM32 etc) which also use FreeRTOS.

Using FreeRTOS gives you much more assurance as it is a commercial product that is used in many other projects and microprocessors. It is industry standard with many people who are expert in it. Not only that but it is a 'real' operating system with 'real' real-time capabilities and tools. You could use FreeRTOS trace and the Percepio tool I previoisly mentioned to help track down this timing/interrupt related problem you have. You can use 'real' resource locks, constraints, rules and tests as all these things come with a 'real' operating system.

I'm not trying to sell you anything, but I'm wondering if the correct path was chosen for your product : Sometimes we want a 'quick prototype' to do a demo and that's fine, but we can then easily fall foul of carrying on with the prototype into production when really the prototype should be thrown away and a strategy for the commercial product agreed and started from scratch.

I hope you understand that I am not trying to be overly critical of you/your company but I know you said you are a novice and I wanted to impart some of my 'wisdom'.