Problems with FreeRTOS for TC 275 using AURIX Development Studio

[dg1vs]

Hello all!

I am currently experimenting with FreeRTOS and the TC275 lite kit. The starting point for my experiments is the FreeRTOS port from the Aurix_AudioAppKit (https://github.com/Infineon/Aurix_AudioAppKit), which is already quite an exciting piece of software, especially since it uses the GTM to generate I2S signals.

 The FreeRTOS software compiles for the TC275 under the AURIX Development Studio and flashing a LED and simple task handling works. However, I have a strange problem.

 When I start the software on the TriCore using the AURIX Development Studio, it always takes about 5 seconds before the system starts and the LED starts flashing. Therefore, I have added the UartTask from the Aurix_AudioAppKit, which regularly outputs information via vTaskGetRunTimeStats(). Enclosed are the two different outputs and the used software.

Start via AURIX Development Studio

 Task statistics 19 - UART RX Count: 0

UART task 54744 <1%

IDLE 4785042 68%

LED task 496 <1%

UART TX task 1033 <1%

Tmr Svc 2111544 30%

UART RX task 1 <1%

Starting after reset

Task-Statistics 18 - Uart RX Count: 0

UART task 52013 2%

IDLE 2539971 97%

LED task 471 <1%

UART TX task 993 <1%

UART RX task 1 <1%

Tmr Svc 143 <1%

So, the cause seems to be in the “Tmr Svc”. However, I have not created this. Can someone help me here?

 Greetings dg1vs

[Di_W]

 xReturn = xTaskCreate( prvTimerTask,
                        configTIMER_SERVICE_TASK_NAME,
                        configTIMER_TASK_STACK_DEPTH,
                        NULL,
                        ( ( UBaseType_t ) configTIMER_TASK_PRIORITY ) | portPRIVILEGE_BIT,
                        &xTimerTaskHandle );

Hi dg1vs,

Please open timers.c for above code.

dw

[dg1vs]

Thank you very much for this advice and pointing me in the right direction. Turning off the software timers by  #define configUSE_TIMERS also turns off this task “Tmr Svc” mentioned in the initial posting. Unfortunately, I didn't see it last night….

However, my basic problem still exists. When I use the AURIX Development Studio and load the software into the controller and want to debug it and just start it via "Resume", it takes about 7-9 second until the LED starts flashing. After a reset the software starts immediately.

Kind regards dg1vs

Karsten

[Di_W]

Hi karsten,

Do you mean if you disable Tmr Svc, it still needs 7~9s after "Resume" command in ADS debugger mode?

In your initial post, the Tmr Svr took longer time in the startup, right?

Could you please clarify a bit? Thanks.

dw

[dg1vs]

Hi dw,

sorry for the somewhat confusing question at the beginning. My main problem was and is that when I start the FreeRTOS-programm using AURIX Development Studio, about 7-9 seconds pass between start  ("Resume" or F8) and a first reaction. After a normal reset, the software starts immediately. The indicator used is the flashing of the LED. The effect is independent of whether "Tmr Svr" is used or not.

So my question is this, what happens in the 7-9 seconds? And why does this effect not occur during a normal reset? This effect is not visible in the example programmes (e.g. STM_Interrupt_1_KIT_TC275_LK).

Kind regards

Karsten

[Di_W]

Hi Karsten,

A suggestion is that after  "Restart", use "Step Into" to trace the code.

Btw,  for the LED example project without RTOS,  I used the onboard miniWiggler to debug.

dw

[dg1vs]

I still have this 9 sec lag problem, between a breakpoint at vTaskStartScheduler(), pressing F8 after reaching this breakpoint and the LED starts blinking.

After a hard reset, the LED start blinking instantly.

Any ideas?

Kind regards

Karsten

 

[Di_W]

Hi dg1vs,

Could you trace where the 9s is between IfxCpu_enableInterrupts(); and vTaskStartScheduler();?

dw

[dg1vs]

I have also partly traced the software between fxCpu_enableInterrupts(); and vTaskStartScheduler(); there are mainly pvPortMalloc call in the heap_4.c file for setting up the tasks.

But to be honest, I am totally confused by now. I have built the same project with a TC277 application kit and as debugger I’m using the Lauterbach debugger now (ok, the active usage phase of the Lauterbach is now at least 5 years ago and so my Lauterbach knowledge is a bit rusty).

The first start after starting with the debugger takes about 10 sec, all further starts via "In Target Reset" begin almost without this strange delay. It looks like there is “something” in the code (or in the tricore) that staring with a debugger control takes unnecessary time. However, I just can't find it.

A start via Power-Off-On or Reset starts immediately.

This weird delay in debugging is relevant after vTaskStartScheduler().

Attached is the current state of the projeckt.

A completely different problem. When I want to debug the user task, the FreeRTOS always runs into a debug16, or configASSERT, probably because the STM keeps running. I have not yet found an option to disable this behaviour. Any ideas?

[Di_W]

Hi dg1vs,

I will ask the developer for this 9s delay issue. About another issue, it would be also related with RTOS and ADS debugging system, I will ask together.

Please note that the RTOS support by ADS free software is not as common as other code examples.

dw

[go2sh]

Hi dg1vs,

I suspect the following: During debugging the STM timer keeps running. (As you mentioned). Can you try to add the following directly at the beginning of main:

STM0_OCS.B = (Ifx_STM_OCS_Bits) {
        .SUS = 2,
        .SUS_P = 1
    };

Maybe you need to include the IfxStm_reg.h file. You shouldn't hit the assert any more and the code should start faster.

An explanation: Normally the STM is running during stopped CPUs to keep a global time base. The problem with FreeRTOS is, that it requires the tickts to be continuous. The assert in the ISR is there to detect dropped ticks in order to keep the systicks in sync with the STM timer.

We'll update the port to include a debugging option.

BR,

Christoph

[dg1vs]

Hi Christoph,

thanks for the hint. I added the code into the port.c file

IFX_INLINE void vPortInitTickTimer()

{

    IfxStm_CompareConfig stm_config;

    IfxStm_initCompareConfig( &stm_config );

    stm_config.comparator = IfxStm_Comparator_0;

    stm_config.comparatorInterrupt = IfxStm_ComparatorInterrupt_ir0;

    stm_config.compareOffset = IfxStm_ComparatorOffset_0;

    stm_config.compareSize = IfxStm_ComparatorSize_32Bits;

    stm_config.ticks = IfxStm_getLower( &configSTM_MODULE ) + portTICK_COUNT;

    stm_config.triggerPriority = configKERNEL_INTERRUPT_PRIORITY + 1;

    stm_config.typeOfService = configSTM_TOS;

    IfxStm_initCompare( &configSTM_MODULE, &stm_config );

    STM0_OCS.B = (Ifx_STM_OCS_Bits) { .SUS = 2, .SUS_P = 1 };

}

At least debugging is now possible. That's really fine. The wired start-up behaviour is not yet solved.

 Kind regards and many thanks

Karsten/dg1vs

[go2sh]

Hi Karsten,

did you adapt the tick count to your STM frequency? Can you place the OCS register update before the init of the STM. Just to make sure the debug doesn't trigger a wrap around. There is a slight delay between reading the current stm value and setting the compare value. If the time is to long, due to debugging, the STM might have to wrap around to trigger an IRQ.

BR,

Christoph