Trouble using FreeRTOS+Trace

alexpabouct wrote on Tuesday, September 09, 2014:

Hello,

I’m trying to implement FreeRTOS+Trace into my application. Up to know i’ve been using FreeRTOS without any issues and decided to give FreeRTOS+Trace a try.

I copied the additional libraries + ports from the FreeRTOS download and can compile everything without any issue.

However, my code no longer works properly if i include the tracing features. I simplified my code to a simple bare bone test but still cannot find the issue.

I am currently working with the STM32F4 Discovery board and am using Eclipse + GCC + OpenOCD as my IDE.

Here is a snippet of code:

void test_task(void *pvParameters)
{
    portTickType last_wake_time;
    last_wake_time = xTaskGetTickCount();

    uint32_t i = 0;
    while(1)
    {
        i++;
        // Delay
        vTaskDelayUntil(&last_wake_time,20 / portTICK_RATE_MS);
    }
}

void nvic_config(void)
{
    NVIC_InitTypeDef NVIC_InitStructure;

    NVIC_PriorityGroupConfig( NVIC_PriorityGroup_4);

}

void main(void)
{
    // Setup system clocks
    SystemInit();
    rcc_config();

    // Init Trace data structure
    vTraceInitTraceData();

    // Setup NVIC
    nvic_config();  

    // Create Tasks
    xTaskCreate(test_task,(signed portCHAR *)"Test ",512,NULL,1,NULL);


    uint8_t flag;
    // Start Tracing
    flag = uiTraceStart();

    // Start Scheduler
    vTaskStartScheduler();

    while(1)
    {
        // No Man's Land
    }
}

When i run my code, the vTraceInitTraceData() and uiTraceStart() both seem to be called correctly (flag returns 1, and the InitTraceData properly configures the RecordData structure).

Where things get wierd is the execution of the task itself. The task is only executed once after which the program gets stuck in void vPortEnterCritical( void ) on line 413,

configASSERT( ( portNVIC_INT_CTRL_REG & portVECTACTIVE_MASK ) == 0 );.

I am running out of ideas on what to look. Any comments or suggestions would be most appreciated! If needed, i can also show my FreeRTOSconfig.h / trcConfig.h.

Thanks,
Alex

rtel wrote on Tuesday, September 09, 2014:

That is a new assert that was placed to ensure non interrupt safe functions are not called from an interrupt.

Can you look at the call stack to see from where in the code the enter critical function is being called? It might be that one of the macros needs changing.

The trace was tested using the Win32 simulator port, which would not have shown this issue as in that port the macro is defined away.

Regards.

alexpabouct wrote on Tuesday, September 09, 2014:

While trying to answer your question, i noticed something very weird. The error isn’t always produced in the same location, depending if im debugging step by step through the function, or if i just let it run through.

If i let it run through, i read configASSERT (…) with the following call stack:

vPortEnterCritical() at port.c:413 0x800498a
xTaskGetTickCount() at tasks.c:1,680 0x8005222
test_task() at main.c:104 0x800031c
pxPortInitialiseStack() at port.c:242 0x8004818
pxPortInitialiseStack() at port.c:242 0x8004818
However if i step into all the functions, i reach the configASSERT (…) with the following call stack:

vPortEnterCritical() at port.c:413 0x800499a
vTraceStoreTaskReady() at trcKernel.c:77 0x80036b6
xTaskIncrementTick() at tasks.c:1,938 0x800532c
SysTick_Handler() at port.c:525 0x8004a58
() at 0xfffffffd
prvPortStartFirstTask() at port.c:280 0x8004870
xPortStartScheduler() at port.c:366 0x8004922

Not sure what to make of it…

Alex

rtel wrote on Wednesday, September 10, 2014:

It sounds like are using the default time source, which is the tick interrupt, rather than telling FreeRTOS+Trace that you are running on a Cortex-M device. If you set the configuration parameter to tell the software the target you are running on the time source will be much higher resolution and provide much better results - plus it will prevent xTaskGetTickCount() from being called by the trace macro.

Alternatively you could change the definition from xTaskGetTickCount() to xTaskGetTickCountFromISR() to prevent the assert, although as just mentioned, to get full benefit from the trace I would recommend a much higher frequency clock source.

Regards.

alexpabouct wrote on Wednesday, September 10, 2014:

Thanks for the input.

From what i can tell, i configured the FreeRTOS+Trace for Cortex-M devices.

i’ve uploaded my FreeRTOS config file and TrConfig file here:

https://dl.dropboxusercontent.com/u/15692375/FreeRTOS_Trace_config.zip

As you can see, i have:

#define SELECTED_PORT PORT_ARM_CortexM

Am i missing something else?

Thanks,
Alex

johankraft wrote on Thursday, September 11, 2014:

We have not yet verified FreeRTOS+Trace with FreeRTOS v8.1.2 and it seems that the new configASSERT will require some changes in our recorder library.

However, there is a quick-fix until our updated v2.7 is released (with some major new features!). Our default critical section is the standard vPortEnterCritical, but for ARM Cortex-M we also have an alternative solution for critical sections, which calls ulPortSetInterruptMask directly. This can be used as a work-around for now. To use this solution, set USE_PRIMASK_CS to 1 (trcConfig.h).

Best Regards
Johan Kraft
Percepio AB

alexpabouct wrote on Thursday, September 11, 2014: