FreeRTOS xTaskIncrementTick() never gets called.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

FreeRTOS xTaskIncrementTick() never gets called.

Jump to solution
3,307 Views
peterfurey
Contributor IV

Hi,

I'm using FreeRTOS with SDK_2.0_MK24FN1M0xxx12 on a custom board. And I'm using the default clock configuration created with the new clock tool in KEx Tools v2.0 (FEI MCG Mode, System clock 20.97152 MHz). Also I'm using the default FreeRTOSConfig.h. I wrote a simple task to periodically print the tick count but xTaskIncrementTick() in task.c never gets called and the tick count remains 0. Any ideas on what the problem is? I'm assuming the SysTick interrupt is enabled by default (bad assumption?).

Thank you,

Peter

 

166922_166922.PNGdebugCode.PNG

Labels (1)
Tags (2)
0 Kudos
1 Solution
2,554 Views
DavidS
NXP Employee
NXP Employee

Hi Peter,

Your event.c had SysTick_Handler() implemented and this was trumping the port.c SysTick_Handler() function causing the tick not to occur properly.

In event.c I did following:

#if 0         //DES 0=test, 1=default code

void SysTick_Handler(void)

{

    g_timeMilliseconds++;

}

#endif

Re-compile and ran and hit breakpoint inside the port.c void xPortSysTickHandler(void) handler.

BTW: when your event.c SysTick_Handler() used, it is working but other  RTOS scheduler stuff needs xTickCount to be incrementing to allow RTOS to function correctly (I think).

Regards,

David

View solution in original post

0 Kudos
8 Replies
2,554 Views
DavidS
NXP Employee
NXP Employee

Hi Peter,

A simple way to have default clocking to the FreeRTOS example code is just to comment out the BOARD_BootClockRUN(); function call like below:

int main(void)
{
BOARD_InitPins();
//DES test BOARD_BootClockRUN();
BOARD_InitDebugConsole();

If you look into the BOARD_BootClockRUN() function it will safely increase the clock and lastly call following:

    SystemCoreClock = g_defaultClockConfigRun.coreClock; 

When "SystemCoreClock" is used by FreeRTOS and peripheral init routines.  So if you have a UART or SysTick running, it will set according to the "SystemCoreClock" setting.

If commenting BOARD_BootClockRUN() makes things work Ok, then something in the KEx Tool might not have been configured right (or it is wrong).

Regards,

David 

0 Kudos
2,555 Views
peterfurey
Contributor IV

Hi David,

Thank you for your response. I tried your suggestion and got the same result. Any other ideas?

Best,

Peter

0 Kudos
2,555 Views
DavidS
NXP Employee
NXP Employee

Hi Peter,

Can you post your project?

I don't have a K24 but hope to run it on the FRDM-K64F.

Regards,

David

0 Kudos
2,555 Views
peterfurey
Contributor IV

Sure, what is the easiest way to do that?

0 Kudos
2,555 Views
DavidS
NXP Employee
NXP Employee

Hi Peter,

When doing a "Reply" there is a "Use advanced editor"  link to the upper right hand corner.  Click it.

The new window that opens has "Attach" at lower left corner of window.  Click it and then attach the ZIP file.

Regards,

David 

0 Kudos
2,555 Views
peterfurey
Contributor IV

Hi David,

My project is attached. Thank you for looking at it.

Best,

Peter

0 Kudos
2,555 Views
DavidS
NXP Employee
NXP Employee

Hi Peter,

Your event.c had SysTick_Handler() implemented and this was trumping the port.c SysTick_Handler() function causing the tick not to occur properly.

In event.c I did following:

#if 0         //DES 0=test, 1=default code

void SysTick_Handler(void)

{

    g_timeMilliseconds++;

}

#endif

Re-compile and ran and hit breakpoint inside the port.c void xPortSysTickHandler(void) handler.

BTW: when your event.c SysTick_Handler() used, it is working but other  RTOS scheduler stuff needs xTickCount to be incrementing to allow RTOS to function correctly (I think).

Regards,

David

0 Kudos
2,555 Views
peterfurey
Contributor IV

Thank you very much David! That event.c module is something that I imported from the sdcard_fatfs_frdmk64f example project when I was trying to get my sdcard/filesystem interface working but I notice now that that project wasn't using FreeRTOS so there was no conflict. I very much appreciate you taking the time to track that down for me, I was stumped.

Best,

Peter

0 Kudos