Skip to main content
dp65
dp65
Associate
July 20, 2014
Question

STM4Cube+FreeRTOS: xTaskIncrementTick() could be called when pxCurrentTCB == NULL

  • July 20, 2014
  • 4 replies
  • 1832 views
Posted on July 20, 2014 at 13:49

I’m running code, generated by STM32Cube and have dropped to HardFault_Handler() on start of execution.

By debugging I have found this issue:

STM32Cube code generator placed xPortSysTickHandler() into SysTick_Handler() for 1 ms tick counting.

xPortSysTickHandler() calls xTaskIncrementTick(), which execute follow code:

...

if( listCURRENT_LIST_LENGTH( &( pxReadyTasksLists[ pxCurrentTCB->uxPriority ] ) ) > ( UBaseType_t ) 1 )

...

But, clock system had initialized before any tasks have been created. 

And interrupt SysTick_Handler() may occurs when no tasks and even scheduler is not running yet.

So, pointer pxCurrentTCB equal to zero at this moment and [pxCurrentTCB -> uxPriority] indicates some random value.

It caused system exception.

As temporary solution I just have added one of task creation procedure before clock initialization. That is not good coding, but works.

And... by the way, when latest version of FreeRTOS will be implemented into Cube?

    This topic has been closed for replies.

    4 replies

    stm32cube-t
    stm32cube-t
    ST Employee
    July 21, 2014
    Posted on July 21, 2014 at 13:47

    Hello,

    Can you please provide the .ioc of your STM32CubeMX project.

    Thank you

    stm32cube-t
    stm32cube-t
    ST Employee
    July 21, 2014
    Posted on July 21, 2014 at 15:29

    This issue will be fixed in a next release. For now you will have to patch 'stm32fxxx_it.c' file manually as follows:

    void

    SysTick_Handler

    (void)

    {

      if

    (

    xTaskGetSchedulerState

    () !=

    taskSCHEDULER_NOT_STARTED

    )

      {

     

    xPortSysTickHandler

    ();

      }

     

    HAL_IncTick

    ();

    }

    dp65
    dp65Author
    Associate
    July 23, 2014
    Posted on July 23, 2014 at 08:13

    Thanks for answer!

    Just for you information - replay fromReal Time Engineers ltd.:

    The clock should not be initialised until the scheduler has started. The sequence used by FreeRTOS is as follows:

    1) Ensure interrupts are disabled.

    2) Configure clock to generate tick interrupts.

    3) Start the first task (which automatically re-enables interrupts).

    So the clock initialisation code must itself be enabling the systick, which it need not do as FreeRTOS will do that itself at the appropriate time.

    One solution for you, which assumes the ST code is not also enabling interrupts, is to simply call taskENTER_CRITICAL (or globally disable interrupts) before the clock initialisation is done. The scheduler will automatically set the global interrupts and critical section state to be correct when it starts.

    Regards!

    D. Popov

    PS: Please find requested .ioc in the attachment

    ________________

    Attachments :

    F4-Cube.ioc : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HzKA&d=%2Fa%2F0X0000000bLG%2F.5NBSf3xf_gHnyEgIctJPlyX1nWf6n1IZSqlLP3R0FE&asPdf=false
    viacheslav
    viacheslav
    Associate
    August 23, 2014
    Posted on August 24, 2014 at 01:05

    In this case you will not be able to run any initialization before FreeRTOS run. Also HAL_delay() will not work as expected because it depends on systick interrupt.

    Terms & ConditionsAccessibility statement