Help Needed: Debugging a FreeRTOS Port for Infineon AURIX TC222 – Context Switching and Scheduler Issues

Libraries
1

Hello FreeRTOS Community,

I am working on FreeRTOS port for the Infineon AURIX TC222 TriCore microcontroller.

Tools: Infineon board TriBoard TC222 (V1.0) with tricore compiler.

Aurix Development studio (1.10.36)

GitHub repository:

I am trying to achieve reliable multitasking and understand the kernel porting requirements for the TriCore architecture. My current implementation has issues with task execution and context switching, and I need help identifying and correcting the underlying problems.

Note: When on debug mode LED toggled but at free run LED did not toggled, I debug but don’t got any lead.

I would appreciate a technical review of the port, particularly:

  • Initial task stack and task context initialization.

  • Context save and restore during task switches.

  • Scheduler behaviour with equal and different task priorities.

  • Tick interrupt and yield handling.

  • TriCore-specific context management and interrupt integration.

  • Any incorrect assumptions in my current port implementation.

My goal is to get a reproducible, working implementation and understand the correct FreeRTOS porting methodology.

If you have experience porting FreeRTOS to Infineon AURIX or other TriCore microcontrollers, I would appreciate any feedback, corrections, or relevant reference implementations.

I can share build logs, debugger traces, compiler details, and a minimal reproduction of the issue.

Thank you for your help.

Regards

2

when you write “when on debug mode,” what exactly do you mean? Do you mean that a debug build runs as expected but a release build doesn’t, or do you mean that the same build runs as expected under debugger control but not when no debugger is attached?

3

One thought, if the change is with a debugger attached, I know that for some processors (I am not familiar with this one) disable the watchdog when a debugger is attached, and that could explain your symptom, that the system traps on a watchdog timeout and just hangs.

4

A related possible explanarion in that case is that a debugger very likely does some behind-the-curtain mcu initialization when the target is reset, and some of that initialization is missing in your startup init code.

5

We have some ports for Infineon AURIX parts which you may want to use as reference:

6

Hello @RAc, @richard-damon ,

Thank you for the reply!

observation:

  1. under debugger control when I put breakpoint inside Task 1 and Task2 then it’s working as expected both Tasks executed. even after breakpoint removed.
  2. under debugger control when no breakpoint then both task not execute means no LED toggled.
  3. same build code when flashed then same observed no LED toggled.

I don’t think it’s a watchdog issue because I didn’t observe any reset here.

I suspected it’s a context switching issue when task switched or context restore or CSA chain broken, interrupt skipping such kind issue.

Best Regards,

Shahbaz Ansari

7

ok, but if you observe the issue with a debugger attached but no breakpoint set, you should be able to analyze the processor state with your debugger. For example, does your Sys tick handler still get called when your target is in non working state? Or is your target perhaps in a fault?