you do not need the critical section in the isr as the isr will by definition run uninterrupted with respect to the task. You would only need it if there was a higher priority isr attempting to use your data concurrently.
Hi Gaurav - that is a good point which I had forgotten about - thanks.
PS: yes, it was a typo, I am talking about taskENTER_CRITICAL_FROM_ISR
Hi @RAc - Yes, I take the point, I was being a bit over-cautious…
Hi Gaurav
Actually, it looks like my port does not support nested interrupts. I looked in FreeRTOSconfig.h and there are no definitions for configKERNEL_INTERRUPT_PRIORITY and similar, and they are not present in the port.
So (according to my updated understanding) it makes sense that there are also not definitions for taskENTER/EXIT_CRITICAL_FROM_ISR? Ie. there is no problem here…
Shame ;-(.
Jon N
Even if I am in danger of repeating myself to boredom… one of the best tools to attack your intermittent problem is tracealyzer, the very best one being a deep trace, but not all boards/tool sets/eco system support that.
Thanks … I think I have read about tracealyzer, but do not know much about it. I am investigating … but I fear our setup might be a little too much off the beaten track for them…
One possiblity is that the list item is getting corrupted. You can try to enable list item integrity checks by setting configUSE_LIST_DATA_INTEGRITY_CHECK_BYTES to 1 in your FreeRTOSConfig.h:
#define configUSE_LIST_DATA_INTEGRITY_CHECK_BYTES 1
Hello Gaurav - hey, that looks really interesting, thanks. I had not come across configUSE_LIST_ DATA_INTEGRITY_CHECK_BYTES before, although I see it was introduced … in 2015.
It doesn’t seem to be well documented/publicised; is that because it is more intended for your internal use?
I will definitely be giving this a try.
Thanks, Jon N
Tracealyzer looks interesting … I am trying to determine what effort it might take to get this running on our core.
What do you get when buying Tracealyzer? Is it the DLL that you use with a debugger to analyse the uploaded trace buffer?
Thanks, jon
Thanks, Jon
Kind of - it is more for debugging list implementation which is not part of public API.
It is a PC application which provides a nice UI to visualize trace and understand your application behavior. This page provides more details - Tracealyzer for FreeRTOS - Percepio FreeRTOS Analyzer for Everyday Use.
“Thanks so much for sharing this! It’s really helpful and much appreciated.”
(updated reply with a slightly different slant - we are getting back to investigating this problem after a bit of a break)
This is to clarify an observation in our code and port.
We have got our FreeRTOS Timer tick set to use the FIRQ interrupt. So (for instance) the interrupt frame is different to a non-FIRQ interrupt.
However the actual tick interrupt C function is not declared (eg. via attribute((fast_interrupt)) to match.
Am I right in thinking that this might cause issues? I am curious how FreeRTOS ports deal with this configuration possibility in general…
Thanks, jon N
First, since the port defines the actual interrupt service routines, it is the port that needs to define things to match what is being done, and if moving the tick interrupt to the FIRQ means a need to change the declaration, the port needs to do that.
Second, the interrupt frame being different won’t matter unless that frame is used to store the registers for resuming the task, but for ARM processors, it isn’t that ISR frame, but the frame from the Pend-SV interrupt that occurs after this ISR leaves.
If you are doing the scheduling as a called function from inside the ISR, then YOU, as the port writer need to be sure to handle the various cases, and still, that function tends to save all the state and not rely on the ISR register save.
Hi Richard, thanks for your reply:
First, since the port defines the actual interrupt service routines, it is the port that needs to define things to match what is being done, and if moving the tick interrupt to the FIRQ means a need to change the declaration, the port needs to do that.
I was partly separating out ‘the port’, which might be agnostic about whether the timer IRQ was an FIRQ or not, and the … ‘application build’, which might choose one way or the other. I don’t know if this is a reasonable thing to tease out in this way…
Second, the interrupt frame being different won’t matter unless that frame is used to store the registers for resuming the task, but for ARM processors, it isn’t that ISR frame, but the frame from the Pend-SV interrupt that occurs after this ISR leaves.
I am not thinking on an ARM port FWIW.
If you are doing the scheduling as a called function from inside the ISR, then YOU, as the port writer need to be sure to handle the various cases, and still, that function tends to save all the state and not rely on the ISR register save.
Indeed … I have not yet fully bottomed out whether I think this is a real issue for us, but wanted to ask a bit around it in general.
Regards, jon N
The processing of “system” resources are in the “Port” layer, which might define them “weak” so a given application can change them, but then that part of the application is actually becoming the application specific port.
As to the mentioning of the ARM port, that was more as to that style of operation. As far as I am familiar, there are basically two ways to handle the task switching, either using an interrupt that will be delayed until any interrupt that is currently running has returned, and that ISR saves all the current processor state, changes current task (by calling the scheduler) and then restores the current processor state for the newly chosen processor.
The other method, if such an interrupt isn’t available, is to call a function that does that processor state save, schedule, and the restore the state, but then you need to handle the fact that the ISR that calls that function, and any ISRs it has nested with, will not complete until that switched out task get resumed. That means this sort of operation needs to either disallow nesting of interrupts, or any interrupt that happens needs overhead to keep track of interrupt nesting and at the very end, see if someone (maybe not itself, but something that nested inside it) requested a rescheduling. If this is the way this port is working, using the FIRQ automatically means nesting is possible, so that needs to be handled. If the original port assumed no nesting, then you will have problems.
Which port are you using? Did you write a FIQ handler which saves the required registers before clobbering them? Just for a quick test, can you change the tick to IRQ and see if the problem goes away?
Hi Gaurav
Yes, we are trying using the tick in a non-FIRQ manner at the moment. I am just trying to examine around the subject, as it were - I would like to be clear about the situation as well as making empirical observations.
Regards, Jon N