Ways to debug freeRTOS code locking?

Hi,
a piece of code is blocking but have no idea what causes it. But the code is relatively simple (no dynamic memory allocation in my part of the code, all functions passing only by value, etc.) very basic. But it locks up somewhere and the debuggers (both ICD 4 and J-link) when halted during the “lock” condition, don’t point/stop/show to any line of code and there is no call stack info displayed at all.

I have a feeling it is caused by something related to freeRTOS (the way I might be using certain functions and/or configuration). But then again I only use simple notifications.

  1. Are there some freeRTOS specific strategies and/or functions to help debug what freeRTOS is doing to figure out why the code is locking?

  2. Maybe I need to enable some of the hook functions? How do I use them for debugging?

I am running a PIC32MZ through the MPLAB interface and Microchip Harmony Configurator. The version is 10.2.

Thank you :slight_smile:

Any suggestion anybody? :slight_smile:

All of the information is in the task’s TCB (task control blocks). Those are accessible and traversable. Many IDEs offer plugins that do that for you and display the info. Check with your IDE’s manufacturer. If that’s not an option, you may need to do that yourself. It’s a fairly good excercise to get a feeling for the inner workings of FreeRTOS… :wink:

Are you able to view the registers in the debugger? If so, have a look at the program counter value and see what it is pointing to in the map file or a disassembly.

To RAc’s point, I think MPLAB has some level of FreeRTOS awareness, so see which task it thinks is running (although you could be in an interrupt).

Make sure you have stack overflow protection set to 2 and configASSERT() defined - then put break points in the stack overflow and assert function to try and stop the debugger before it goes into the weeds.

Are you using any kind of semi-hosting? If so, it will probably mess up the debuggers ability to control the device (true for ARM anyway).

Use a trace tool such as Percepio’s tracealyzer (I think MPLAB may have that facility too?), or Segger’s SystemView for FreeRTOS.

Inspect the hardware registers to see if you are inside an interrupt, and if so, which interrupt you are in.

Install a different interrupt hander for each interrupt in case an interrupt is executing unintentionally.

Thank you both.

Richard,
What is the “semi hosting” you mention?

Yes, I can see the registers but not when that specific issue happens. I am trying all the other suggestions, very useful!!

Thank you

Semi hosting is where you access the IO on the computer running the development tools and debugger, rather than accessing the IO on the target hardware. For example, if you printf() a string on the target hardware, it appears in the console of the debugger rather than being output via the serial port (or LCD display, or whatever) of the target hardware. It is a very useful technique, but on ARM at least, semi hosting uses some of the system interrupts that are also used by FreeRTOS so it results in some very weird and unpredictable behavour.

re. setting stack overflow protection set to 2, in the API manual it says “The stack overflow hook function is called should any of these 16 bytes not remain at their initial value.”

How do I define that hook function?

In MPLAB there are other options to enable other hook functions just by ticking a check box in the configurator. But there isn’t one for “stack overflow”.

  1. is it available in freeRTOS version 10.2?
  2. if yes, how do I define it?
  3. just in case it is already in the code without needing a configuration flag from the MPLAB configurator, what is it called? so I can search for it?

Thank you

I guess there are examples here in forum. My hook for instance end up in an assert.