Hal bug using rtos

[roberto239955_stm1_stmicro]

Posted on August 05, 2014 at 12:50

I imported an example with  RTOS (FatFs_uSD_RTOS) and I found some bug. In function HAL_Init() is called HAL_SYSTICK_Config()  but  SysTick_Handler()  call xPortSysTickHandler() before osKernelStart() so we have an HardFault_Handler.

The systick is configured also in function HAL_RCC_ClockConfig called by SystemClock_Config always before  osKernelStart().  In addition the function  HAL_IncTick() is not called in SysTick_Handler() and due the priority level is not possible add this funcion, #hal-rtos-bug

[Tesla DeLorean]

Posted on August 05, 2014 at 13:30

Seem to recall this being brought up as an issue/bug in the forum where CUBE/HAL issues are normally discussed.

[DEAD LINK /public/STe2ecommunities/mcu/Lists/STM32Java/AllItems.aspx]https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Java/AllItems.aspx

[roberto239955_stm1_stmicro]

Posted on August 05, 2014 at 14:28Sorry you are right, dscussion aready present. My fault. By the way the SD driver works with sd card up to 4GB. If I use a 8G, the program formats the SD in  4Gb Fat32.   

[Tesla DeLorean]

Posted on August 05, 2014 at 16:50

ST has a long history of broken SDIO libraries, it has a lot to do them using byte offset addressing for things which are inherently block addressed. A ''4GB'' cards is around 3.95GB in the 32-bit number space, larger cards need 64-bit byte addressing.

Someone reported an issue with the capacity computation needing 64-bit casting.

[Tesla DeLorean]

Posted on August 05, 2014 at 20:11

https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Java/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Java/STM32Cube%20SDHC%20capacity%20bug%20%28solved%29&FolderCTID=0x01200200770978C69A1141439FE559EB459D758000F9A0E3A95BA69146A17C2E80209ADC21&currentviews=181