Skip to main content
Osto
Osto
Senior
July 20, 2014
Question

Huge assert bug in STM32CubeMX V4.3 with STM32Cube V1.0

  • July 20, 2014
  • 2 replies
  • 892 views
Posted on July 20, 2014 at 14:45

There is a huge bug in STM32CubeMX with STM32Cub V1.0 when full assert is enabled.

When I make a project with timers or SPI and full asser is enabled, then the program hit the assert when the HAL_init function is called in main.

The reason is that the Cube dont set all values of the structure htim and dont clear it because for the configured case a lot of values are not important but the assert configuration checks all parameters regardless if they are used or not. Because of random values in these ram sections, the values make no sense.

This cause a permanent jump to assert function without any reason. This happen with all timers and sometimes with SPI. I cant use them at all.

attached you have the IOC file.

Please forward this to the related team.

Thanks
    This topic has been closed for replies.

    2 replies

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

    Hello,

    There is a known issue when using freeRTOS.

    Can you please confirm you reproduce your issue after patching the stm32f4xx_it.c file as indicated in thread: [DEAD LINK /public/STe2ecommunities/mcu/Lists/STM32Java/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/STM32Java/STM4Cube%2bFreeRTOS%20xTaskIncrementTick%28%29%20could%20be%20called%20when%20pxCurrentTCB%20%3d%3d%20NULL&currentviews=17]https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Java/Flat.aspx?RootFolder=%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fSTM32Java%2fSTM4Cube%2bFreeRTOS%20xTaskIncrementTick%28%29%20could%20be%20called%20when%20pxCurrentTCB%20%3d%3d%20NULL

    Thank you

    Osto
    OstoAuthor
    Senior
    July 23, 2014
    Posted on July 23, 2014 at 02:09

    Hi,

    No, this dont solve my problem. My problem start before the scheduler or anything else is started. The problem starts during the init phase of the main().

    When full assert is enabled, every HAL subroutine checks the parameter if they are in range at beginning of the subroutine. These are call from the HAL/Cube init procedure but when I configure in Cube a simple up counter, then the valuese for Output compare  (as an example) are not set and has random values.

    The HAL function check also these values regardless of if they make sense or not (needed for this particular case). If the random vale is out of range then the init will fail and assert hited even when there is no reason to do that. This happen only because of random values in memory.

    In the older version of HAL there was a clear function for the structure but the Cube don produce such code. It should call an init function to clear all values and set then to a valid value.

    If its not clear, please let me know, I will sen you code fragments but its very easy to simulate this error. Configure a timer, activate full assert then generate the project, load to debug and before start set all bytes of the htimx structure to 0xff or fill the whole ram with 0xff before you start your programm. Then you see that it will never work. If you disable full assert, then everything is working fine.

    Right now I disable the full assert to be able to develop my project but I need it to see, if my programm is working correct or not.

    Regards
    Terms & ConditionsAccessibility statement