Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT




Loading

Trouble using FreeRTOS+Trace

Posted by alexpabouct on September 9, 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 testtask(void *pvParameters) { portTickType lastwaketime; lastwake_time = xTaskGetTickCount();

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

}

void nvicconfig(void) { NVICInitTypeDef 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( ( portNVICINTCTRLREG & portVECTACTIVEMASK ) == 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


Trouble using FreeRTOS+Trace

Posted by rtel on September 9, 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.


Trouble using FreeRTOS+Trace

Posted by alexpabouct on September 9, 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


Trouble using FreeRTOS+Trace

Posted by rtel on 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.


Trouble using FreeRTOS+Trace

Posted by alexpabouct on 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/FreeRTOSTraceconfig.zip

As you can see, i have: ~~~~~~~~~~~

define SELECTEDPORT PORTARM_CortexM

~~~~~~~~~~~

Am i missing something else?

Thanks, Alex


Trouble using FreeRTOS+Trace

Posted by johankraft on 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 USEPRIMASKCS to 1 (trcConfig.h).

Best Regards Johan Kraft Percepio AB


Trouble using FreeRTOS+Trace

Posted by alexpabouct on September 11, 2014


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS