STM32Cube bugs?

[Breukers.Ron]

Posted on April 19, 2014 at 14:27

I started using the STM32Cube using for now the STM32F401 discovery board and Keil software. I like the setup very much as it can make initialization a breeze.

However I have a few comments(bugs?). - If I use the FREERTOS, and I try to compile the code it comes with the error ''freeRtosTest Configuration\freeRtosTest Configuration.axf: Error: L6218E: Undefined symbol xQueueGiveMutexRecursive (referred from cmsis_os.o).'' I have to comment out the line 444, 491,494 and 532  of queue.c. - In the configuration of the target options it always reverts to JTAG mode under debug-settings - The most problems come from the RTC module. I made a small test program with flashing LEDs to test the RTOS setup. It all works until I enable the RTC module. In the debugger I found that the system hangs at the HAL-RTC-Init instruction. I configured the RTC clock using the LSI. My question is if I made somewhere a mistake in the STM32Cube setup or if anyone else has the same problem. #bug-rtc-initialisation-solved #stm32cube #freertos-compiler-error #bug-in-stm32f4xx_hal_sd #rtc #status-update

[neo911]

Posted on April 21, 2014 at 10:49

Hi,

I can help on FreeRTOS part as I can reproduce the issue (you're not alone ;) ). The ''root cause'' seems to be the cmsis_os.c file calling two functions (xSemaphoreTakeRecursive and xSemaphoreGiveRecursive) which are not defined if configUSE_RECURSIVE_MUTEXES (a FreeRTOS flag) equals to 0 which is the default case for STM32Cube. Keil fails while IAR does not mind... (maybe different settings in the tool chains?).

Instead of commenting some lines in queue.c, I suggest you to set USE_RECURSIVE_MUTEXES to ''Enabled'' when configuring FreeRTOS.

A cleaner solution would be that cmsis_os.c takes into account FreeRTOS settings and avoid the use of undefined functions in some cases as the trouble will occur with Keil each time the user sets the flag to 0.

Hope it can help you.

Rgds.

[Breukers.Ron]

Posted on April 21, 2014 at 12:12

Hi,

Of course you are right. The commenting-out was just to confirm the problem. I left it as it was since it compiled OK. I just modified it again. Thanks. By the way I will add another post below with a bug in the SDIO HAL routine I found.

[Breukers.Ron]

Posted on April 21, 2014 at 12:19

I am trying to get the fatFs working. I added a 4GB micro SD card to the STM32F401Disco board. The USB seems to be working but I found a few strange effects.

First in debugging I found that the system links always DMA, even if it is not setup in STM32cubeMX. After setting up the DMA I found, using the debugger, that the SD_PowerOn routine fails.With a breakpoint at line 2446 the error state after sending CMD55 is SD_ILLEGAL_CMD.

[Breukers.Ron]

Posted on May 11, 2014 at 13:30

A quick status update on my progress. (for reference I use Keil  uV5 and STM32F401Disco)

The problem with the USB was due to a too low level for the heap. Standard setting is 0x2000. I use FREERTOS, FatFS and 4 wire SD. I need 0x4000 for the heap, mostly due to the RTOS. I am still struggling with the ''usbd_storage_if.c'' interface, but I am positive that this will work soon. However in my case I still have problems with the RTC. When I enable the RTC in the STM32CUBE the system hangs in the RTC initialization code. It seems as if the tick counter remains always at 0. I pushed this problem back for now by keeping the RTC out of the system. The default stack setting of 0x4000 seems very high, but I will optimize this at a later time.

[stm32cube-t]

Posted on May 23, 2014 at 12:51

Hello,

Could you provide us with your STM32CubeMX project configuration file (.ioc extension) so that we can try to reproduce your RTC issue. Thank you.

[gk]

Posted on May 26, 2014 at 06:50

>>> I found that the system hangs at the HAL-RTC-Init instruction.

Maybe it's not in this case but with STM32F4Discovery lost many hours before RTC runs  with LSE, problem was simply, as far I remember RTC will need turn on clock after remove battery voltage.  if(!(*(volatile uint32_t *) (BDCR_RTCEN_BB))) __HAL_RCC_RTC_ENABLE();

[Breukers.Ron]

Posted on June 08, 2014 at 18:08

I am using the uVision 5. I use the internal clock, so no crystal for the RTC oscillator.

I attach the .ioc file for your reference. I appreciate your help. ________________ Attachments : Tracklogger_F401.ioc : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HzT4&d=%2Fa%2F0X0000000bMF%2FUGlLW.IG1tpr0yrenbIPVzv0t2XeQhQrv2gwVJHhmEk&asPdf=false

[Breukers.Ron]

Posted on June 09, 2014 at 00:44

Some additional information to help debugging:

- The RTC initialisation sequence times out on waiting for the RTC_ISR_INITF(line 1441 of STM32F4xx_hal_rtc.c), even when I increase the RTC_TIMEOUT_VALUE. - The wakeup interrupt (RTC_WKUP_IRQHandler) is never triggered. - I suspect (but have no proof yet) that the problem is related to FREERTOS. I am going to build without the RTOS and see if things work then. - I no longer use the discovery board as the PCB's for our product development came in. I appreciate any hints you may give me. Ron

[Breukers.Ron]

Posted on July 10, 2014 at 11:44

BUG FOUND

My project has been on hold for a while due to some other urgent project we had to finish first. I recently took up the RTC problem and I found that the RCC->BDCR register was 0x00000200, so the RTC clock was disabled and the RTC clock source was also switched off!! After adding the line RCC->BDCR |= 0x8200 everything functions. For your info, I use the LSI clock for the RTC. I hope this helps someone with the same problem.