This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMDX570LC43HDK: Running project using GCC toolchain

Part Number: TMDX570LC43HDK
Other Parts Discussed in Thread: HALCOGEN

Tool/software:

Hello!

I've being trying to run a project for a TMS570 microcontroller using the GCC toolchain and FreeRTOS. I've managed to get the project to compile and even to run a simple blinky program, but it fails in run-time when trying to do the same using tasks.

I've performed the compilation by downloading a big-endian version of the arm gcc compiler and setting it accordingly in CCS. I've followed the steps set by Jonathon S. in the arm forum: https://community.arm.com/support-forums/f/compilers-and-libraries-forum/49616/latest-arm-gcc-compiler-for-big-endian-processors (also explained in https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1020406/tms570ls1224-how-to-build-and-link-workable-code-for-a-big-endian-system-such-as-a-hercules-tms570-mcu-using-a-gcc-toolchain/3771079?tisearch=e2e-sitesearch&keymatch=tms570%20gcc#).

The first problem I've encountered is with the os_mpu_wrappers.c prvRaisePrivilege() function, as the ams( " swi 1 ") instruction (added when selecting the GCC Tools in HALCoGen) starts an infinite loop of assembly instructions.

I attach the project I have been working with.

GCCMinimal.zip

Thank you in advance!

  • Hi,

    The swi 1 instruction (Software Interrupt 1, which triggers an SVC - Supervisor Call) is fundamental to how FreeRTOS manages privilege escalation and task switching on ARM Cortex-R/M processors. When this instruction causes an infinite loop, it almost always points to one of the following core issues:

    1. Incorrect SVC Handler Setup (Most Likely): The CPU is not jumping to the correct FreeRTOS SVC handler (vPortSVCHandler) after the swi 1 instruction.
    2. Fault within the SVC Handler: The vPortSVCHandler itself is encountering an exception (e.g., MPU fault, stack overflow, unaligned access) which then triggers another exception, potentially leading to a loop if the fault handler is also misconfigured or re-triggers the original fault.
    3. Endianness Mismatch in Context Switching: The assembly code within the FreeRTOS port (specifically port_asm.s or similar) that saves and restores the CPU context during an SVC might be assuming little-endian byte order for stack operations, while your system is big-endian. This would corrupt the stack frame and lead to unpredictable behavior or loops.
    4. Incorrect Return from SVC: The SVC handler is not returning correctly, causing the swi 1 instruction to be re-executed repeatedly.

    Try below things once:

    1. Start with the SVC Vector: This is the most common cause of an infinite loop immediately after an swi instruction. Use your debugger to see exactly where the PC goes after swi 1.
    2. Examine sys_startup.asm: Confirm the SVC vector entry.
    3. Step through vPortSVCHandler: If the vector is correct, step through the assembly of the SVC handler to pinpoint where it goes wrong. Pay close attention to stack operations and MPU-related instructions.
    4. Review port_asm.s for Endianness: If the issue persists, carefully compare the LDMIA/STMDB instructions and any other stack manipulation in your FreeRTOS port_asm.s with a known big-endian ARM port (if you can find one, or consult ARM architecture manuals for big-endian stack conventions).

    --
    Thanks & regards,
    Jagadish.