I have encountered some issues while debugging freertos tasks

1.selected tc233 controller and created a new project on Aurix Development studio
2. downloaded freertos and Imported the FreeRTOS source code to newly created project.
3.I made some modifications to the FreeRTOS settings and port files according to the controller.
4.I called the timer in port files for 1ms (it will trigger interuupt every 1ms)
5.I created a tasks and set priorities according to the freertos stanndards.

I observed some scenarios while debugging

  1. When I put breakpoint on vTaskStartScheduler() in main or timer_function which i have generated for 1ms, (which I have called in Port.c)
    which is getting stucked at

void IfxCpu_Trap_contextManagementError(uint32 tin)
{
volatile IfxCpu_Trap trapWatch;
trapWatch = IfxCpu_Trap_extractTrapInfo(IfxCpu_Trap_Class_contextManagement, tin);
IFX_CFG_CPU_TRAP_CME_HOOK(trapWatch);
IFX_CFG_CPU_TRAP_DEBUG;
__asm(“rslcx”); /* Restore lower context before returning. lower context was stored in the trap vector */
__asm(“rfe”);
}

  1. If I put breakpoint on vTaskSwitchContext() function which is getting stucked over there only

  2. If I don’t put any breakpoints on vTaskStartScheduler() or port file timer interuppt related functions or vTaskSwitchContext(); which is working fine tasks are running as expected.

  3. If I run continuously without any break point my tasks are running fine, once stop the debug which is going to below function, I assume this is IDLE Task
    static portTASK_FUNCTION( prvIdleTask, pvParameters )
    {
    while (1)
    {

}
}

  1. In FreeRTOSConfig.h file, i make it #define configUSE_IDLE_HOOK as 1, when ever i stop execution everytime which is going to vApplicationIdleHook(); function

6.Can I Run Freertos tasks with a 250 microseconds tick? If not , what is the expected tick to run tasks

These are my observations, Are they expected behaviour ? if not, Does anyone please provide your valuable inputs

This does not seem to be FreeRTOS issue but more of a toolchain issue. Please reach out to Infineon for better response.

Thank you for your inputs @aggarg