xTaskDelay(3000) has strange behaviour

Posted by on April 19, 2011

this time a not so stupid question (hopefully) 😉

I know there are not so many people out there usinf Fujitsu MCUs, but perhaps did somebody experience similar behavior with another MCU and has an idea how to solve this problem.

I am working with a Fujitsu FX MCU (the M96F348HSB). Currently I am implementing a few test tasks to see if FreeRTOS is working properly. I have one task that toggles an LED every 3000 ms (BlinkTaskSlow), another task toggles another LED every 1000 ms (BlinkTaskFast).

I expected such a behavior (0 means LED off, 1 means LED on):

BlinkTaskSlow: 000111000111...
BlinkTaskFast: 010101010101...

But they behave like this:

BlinkTaskSlow: 000111000001110000011100000111...
BlinkTaskFast: 010101010101010101010101010101...

The tasks are implemented as follows:

void vBlinkTaskSlow(void * pvParameters)
portTickType xLastWakeTimeSlow = 0;
portTickType xFrequencySlow = 3000 / portTICK_RATE_MS;
xLastWakeTimeSlow = xTaskGetTickCount();
for(;;) {
vTaskDelayUntil( &xLastWakeTimeSlow, xFrequencySlow );
PDR06_P0 = ~PDR06_P0; /* this toggles a LED */

void vBlinkTaskFast(void * pvParameters)
portTickType xLastWakeTimeFast = 0;
portTickType xFrequencyFast = 1000 / portTICK_RATE_MS;
xLastWakeTimeFast = xTaskGetTickCount();
for(;;) {
vTaskDelayUntil( &xLastWakeTimeFast, xFrequencyFast );
PDR06_P2 = ~PDR06_P2; /* this toggles a LED */

The tasks are started within the main() function:

( signed char * ) "BlinkTaskSlow",

( signed char * ) "BlinkTaskFast",

Even if I only start BlinkTaskSlow, this tasks toggles its LED not regularly (it is switched on 3000 seconds, then it is turned off for 5000 seconds).

I tried to change the priorities of the tasks, but it does’nt matter whether BlinkTaskSlow or BlinkTaskFast has the higher priority. Even if both have the same priority they behave as described.

I also implemented a tick hook function to see if the tick is generated correctly. The implementation of the tick hook function is:

void vApplicationTickHook( void )
static portTickType xHookTickCount = 0;
if ( ( xHookTickCount % ( 3000 / portTICK_RATE_MS ) ) == 0 ) {
PDR03_P3 = ~PDR03_P3;
xHookTickCount = 0;

This function should toggle another LED in the same frequency as BlinkTaskSlow should do. Surprisingly the hook function toggles its LED exactly in the same was as BlinkTaskSlow (000111000001110000011100000 instead of 000111000111000111).

I had a closer look at the hook function and monitored the LED with an oscilloscope. I recognied that the LED is toggled two times within its 5000 ms off-phase. The interval between the two toggles is 4,00 ms, which is two times the Tick frequency I use (500 Hz).

The tick frequency is correct. I inserted a port toggle at the top of the Interrupt Service Routine that creates the tick and measured the toggle frequency with an oscilloscope. Only at the point where the two 4,00 ms toggles (mentioned above) occur, the tick is stopped for that period of time.

The FreeRTOSConfig.h is set up as follows:


/* Device specific includes. */
#include "mb96348hs.h"

* The below define should be same as the option selected by the Memory
* Model (Project->Setup Project->C Compiler->Category->Target Depend )
* Valid settings here include:
* ------- Memory models ---------DataCode
* portSMALL16 Bit16 Bit
* portMEDIUM16 Bit24 Bit
* portCOMPACT24 Bit16 Bit
* portLARGE24 Bit24 Bit
#define configMEMMODEL portMEDIUM

/* Demo specific definition - set this to 1 if you want to include the task
that writes trace and debug information to the UART. If it is set to 0 then
the ComTest tasks will be included in place of the trace task. */
#define INCLUDE_TraceListTasks0

* Application specific definitions.
* These definitions should be adjusted for your particular hardware and
* application requirements.
#define configUSE_PREEMPTION1
#define configUSE_IDLE_HOOK0/* 1 by default */
#define configUSE_TICK_HOOK1
#define configMINIMAL_STACK_SIZE( ( unsigned short ) 180 ) /* This can be greatly reduced when using the small or medium memory model. */
#define configCPU_CLOCK_HZ( ( unsigned long ) 48000000 )/* Clock setup from start.asm in the demo application. */
#define configCLKP1_CLOCK_HZ( ( unsigned long ) 48000000 )/* Clock setup from start.asm in the demo application. */
#define configTICK_RATE_HZ( (portTickType) 500 )
#define configMAX_PRIORITIES( ( unsigned portBASE_TYPE ) 6 )
#define configTOTAL_HEAP_SIZE( (size_t) (3000) )/* was 20000 before */
#define configMAX_TASK_NAME_LEN( 20 )
#define configUSE_16_BIT_TICKS0
#define configIDLE_SHOULD_YIELD1
#define configUSE_MUTEXES1
#define configUSE_TRACE_FACILITY0/* 1 by default */
#define configCHECK_FOR_STACK_OVERFLOW1/* 0 by default */
#define configUSE_TIMERS1
#define configTIMER_TASK_PRIORITY( configMAX_PRIORITIES - 2)
#define configTIMER_QUEUE_LENGTH5

/* Co-routine definitions. */
#define configUSE_CO_ROUTINES0
#define configMAX_CO_ROUTINE_PRIORITIES( 2 )/* 4 by default */

/* Set the following definitions to 1 to include the API function, or zero
to exclude the API function. */
#define INCLUDE_vTaskPrioritySet1
#define INCLUDE_uxTaskPriorityGet1
#define INCLUDE_vTaskDelete1
#define INCLUDE_vTaskCleanUpResources1
#define INCLUDE_vTaskSuspend1
#define INCLUDE_vResumeFromISR1
#define INCLUDE_vTaskDelayUntil1
#define INCLUDE_vTaskDelay1
#define INCLUDE_xTaskGetSchedulerState1
#define INCLUDE_xTaskGetCurrentTaskHandle1


#endif /* FREERTOS_CONFIG_H */

Does anybody have an idea what is going wrong there?

Thanks in advance for your help!

RE: xTaskDelay(3000) has strange behaviour

Posted by on April 20, 2011
And again, I found the answer: i forgot to disable the watchdog in my bootloader :

I implemented a trace task (from the FreeRTOS demo project) to send debug information to UART0. I wondered why I periodically received the start message of my trace task. I then compared the re-transmission frequency of the trace task with the frequency of the 4,0 ms toggles mentioned above and found out that they were equal. The only reason why that would happen was a reset of the microcontroller, which lead me to the watchdog…

Perhaps this helps a few people out there 🙂