A FreeRTOS task suddenly does nothing

2
votes

I'm developing a real time system with FreeRTOS on an STM3240G board.

  • The system contains some different tasks ( GUI, KB, ModBus, Ctrl, etc . . )
  • The tasks have different priorities.
  • The GUI seems to display a little slowly.

So I use a Profiler software to see what is going on between the different tasks during a run. This profiler shows me which task was running at each moment ( microsecond) and what interrupts had arrived.

This profiler enables me to "mark" different locations on the code so I know when it was there. So I run the program and make a record.

I looked at the record and I saw that (for example) Ctrl task was between two lines of code for 15 milliseconds (this time change in size) there was not any task change no interrupt arrived and after this time the system continues normally from this point according to the record and my marks.

I tried closing disabling different interrupts without any success. Has anyone any idea what it could be?

1
scheduled-tasksmicrocontrollerstm32freertos
What happens when you use a debugger between those lines? Also are you sure you a not in an interrupt that the profiler is unaware of? – Realtime Rik
Do you use portENTER_CRITICAL() anywhere, since this disables interrupts and therefore task switches cannot occur, or do you block in any interrupts? I would comment all interrupt code out but keep the program flow the same, then see if you get the same behaviour - isolate the problem. – Ed King
This is the question which cannot be answered remotely. All RTOS apps have so tasks and use interrupts. The question why it does not work as I expect is just off-topic here – 0___________

1 Answers

0
votes

On the eval board, there is a MIPI connector that supports ETM trace - a considerable luxury/advantage over other development boards! If you also have one of the more expensive debug adapters that also support ETM trace (like for example, uTrace or J-Trace or ULINKpro or I-jet Trace), you should use it to trace the entire control flow without having to instrument tasks and ISRs.

Otherwise, you should re-check if really every IRQ handler has been instrumented (credits to @RealtimeRik, who pointed this out) at a low-enough level so that the profiler can really spot it. Especially if you are using third-party libraries, it may be that some IRQs are serviced by handlers you (or the profiler) doesn't have the code of. As I had to make this experience once myself, I suggest you review the NVIC settings carefully to re-check if there is an ISR you haven't been aware of.

Another question is how the profiler internally works. If it is based on ETM/TPIU or ITM/SWO tracing, see above. If it creates and counts a huge number of snapshots, there might be some systematic cases which prevent snapshots to be made in a particular part of the software:

Could it be that a non-maskable interrupt or exception handler is running in a way that cannot be interrupted by the mechanism that collects snapshots? Could it be that the timing of the control task correlates (by some coincidence) to a timing signal used for snapshots? What happens if you insert some time-consuming extra code in front of the unexpected "profiling gap" (e.g., some hundreds or thousands of NOPs)?