TMS570LC4357: Freertos code with GCC tools from halcogen getting stuck at vPortEnterCritical()

Hi Kamlesh,

We have one internal AI tool which can analyze all the old, related threads of this controller along with its document. And i got some suggestions from it, could you please check them once?

TMS570LC4357 FreeRTOS with GCC Getting Stuck at vPortEnterCritical()

Based on the information available and common issues with FreeRTOS on TMS570 devices with GCC, here are the most likely causes and solutions:

Most Common Root Causes:

1. Interrupt Configuration Issues

The TMS570LC4357 uses a Vectored Interrupt Manager (VIM) that requires proper initialization before FreeRTOS can manage interrupts correctly(0). The vPortEnterCritical() function manipulates the ARM Cortex-R4 CPSR register to disable interrupts, and if the VIM or interrupt system isn't properly configured, this can cause the system to hang.

Solutions:

• Ensure VIM is properly initialized before calling vTaskStartScheduler()
• Verify that the interrupt vector table is correctly initialized in VIM RAM (address 0xFFF82000)(0)
• Make sure FIQ and IRQ are properly enabled in the CPSR register before starting the scheduler(3)

2. GCC Compiler Optimization Issues

GCC 7.5 may optimize critical inline assembly code differently than TI's compiler, potentially breaking the interrupt enable/disable mechanisms in portmacro.h.

Solutions:

• Try adding volatile keyword or compiler barriers around critical sections
• Reduce optimization level (try -O1 or -O0 for testing)
• Check if the inline assembly for interrupt disable/enable is correctly implemented for GCC syntax
• Verify that __asm directives are compatible with GCC (GCC uses different syntax than TI compiler)

3. Stack Configuration Problems

FreeRTOS requires properly configured stacks for each task and the system stack.

Solutions:

• Verify stack sizes are adequate in HALCoGen configuration
• Ensure the linker script allocates sufficient memory for FreeRTOS heaps
• Check that configTOTAL_HEAP_SIZE in FreeRTOSConfig.h is appropriate

4. System Initialization Order

The order of initialization matters significantly with HALCoGen-generated code.

Recommended initialization sequence:

1. _coreInitRegisters_() / _coreInitStackPointer_()
2. System initialization (clocks, flash, etc.)
3. VIM initialization
4. Enable IRQ/FIQ in CPSR
5. Create FreeRTOS tasks
6. vTaskStartScheduler()

5. MPU/Cache Configuration

If MPU or cache is enabled, incorrect configuration can cause issues with FreeRTOS operation.

Solutions:

• Try disabling MPU initially to isolate the issue
• If using cache, ensure write-through mode is configured(8)
• Verify memory regions are properly configured for code and data

Debugging Steps:

1. Add breakpoints before and inside vPortEnterCritical() to see exactly where it hangs
2. Check CPSR register - verify interrupt bits are in expected state
3. Verify VIM registers - check IRQINDEX, FIQINDEX, and interrupt enable registers
4. Test with minimal configuration - create single task with minimal code
5. Compare with TI compiler - if possible, test with TI ARM compiler to isolate GCC-specific issues

Code Modifications to Try:

In your portmacro.h, ensure the critical section macros are GCC-compatible:

#define portDISABLE_INTERRUPTS() \
    __asm volatile ("CPSID if" ::: "memory")

#define portENABLE_INTERRUPTS() \
    __asm volatile ("CPSIE if" ::: "memory")

HALCoGen Configuration Checklist:

• ✓ FreeRTOS enabled in HALCoGen
• ✓ Correct GCC toolchain selected
• ✓ VIM properly configured
• ✓ Sufficient heap/stack memory allocated
• ✓ System clock properly configured

--
Thanks & regards,
Jagadish.