2

How do you debug an RTOS application? I am using KEIL µVision and when I hit debug, the program steps through the main function until the function that initializes the RTOS kernel and then you can't step any further. The code itself works though. It is not mine btw, but I have to work on it. Is this normal behavior with RTOS applications or is this related to the program?

neolith
  • 699
  • 1
  • 11
  • 20

3 Answers3

4

Yes, this is normal. You need to set breakpoints in the source code for the tasks that were created in main(): the only purpose of main() in a FreeRTOS application is to :

  1. initialize the hardware,
  2. create the resources (timers, semaphores...) and tasks your application will need,
  3. start the scheduler

The application should never return from vTaskStartScheduler() if they were enough resources available.

Frant
  • 5,382
  • 1
  • 16
  • 22
3

Put break-points at the entry point of each task you need to debug. When you step the over the scheduler start (or simply run) the debugger will halts at the first task that runs. When that task blocks, some other task will be selected to run according to the scheduling rules.

Generally when debugging and you reach a blocking call, step-over it, other tasks may run and the debugger will stop at the next line only when the task becomes ready (depending on the nature of the blocking call). Often you will want to predict what task will run as a result of the call, and put a breakpoint in that task. For example if you issue a message send, you might place a breakpoint after the message receive call of the receiving task.

The point is you cannot "step-through" a context switch unless you have the RTOS source or do it at the assembler level, which is seldom useful or productive, and will not work for preemption.

You get a somewhat better RTOS debug experience and tool support in Keil if you use Keil's own RTX5 RTOS rather then FreeRTOS, but all of the above remains true.

Clifford
  • 88,407
  • 13
  • 85
  • 165
1

Yes, this is an expected behaviour. The best way to debug a RTOS application is to place breakpoints at all tasks, key function entry points and step debug.

The debugger supports various methods of single-stepping through an application as in below link. http://www.keil.com/products/uvision/db_exe_step.asp

Typical challenges in debugging RTOS application can be dealing with interrupt handling, synchronization issues and register/memory corruption.

Keil µVision's System Analyzer enables one to view the program execution time frame, status of each thread. It shall also help in viewing interrupts, exceptions if tracer is enabled.

Brema
  • 43
  • 1
  • 1
  • 6