STM32Cube - Barebone FreeRTOS + Lwip on F207

[abrous3d]

Posted on April 16, 2014 at 20:17

Hello to all,

I just set up a bare bone project for my F207VC custom board using the new STM32Cube. The board is tested and it is working perfectly with FreeRTOS 6.1.0 and Lwip 1.3.2. The used PHY is a Micrel KSZ8051RNL on RMII. Frequency is set to 120MHZ. Stack sizes are 0x2000 and 0x2000 respectively. SysTick timer and Ethernet global interrupts are on while interrupts are set to 4 bits of pre-emption and 0 bits subpriority. There is no user code in the project, just what I got from Cube. The code crashes right after entering osKernelStart with Hard Fault. Regardless what I tried I cannot make it work. Any ideas ?   Any help or example projects on how to setup properly STM32Cube for FreeRTOS  (and maybe lwip) would be a great help for many people out there since this is a very common combination. Thanks in advance. #reporting-bugs-effectively #stm32cube

[Tesla DeLorean]

Posted on April 16, 2014 at 21:18

There is no user code in the project, just what I got from Cube. The code crashes right after entering osKernelStart with Hard Fault. Regardless what I tried I cannot make it work. Any ideas ?

Hard Faults have got to be one of the easiest to solve, the processor provides you with tons of data so you can see exactly where something failed, if you write the Handler properly you can print all this to a terminal.  The problem with Code Generators, is that they require no engineering/diagnostic talent to use, and you become reliant on them to generate perfect code. They don't foster a skill set needed for dev work.Any help or example projects on how to setup properly STM32Cube for FreeRTOS  (and maybe lwip) would be a great help for many people out there since this is a very common combination. Yeah, I'm not buying the stats on that, very few people are using Cube for anything right now. People with a lot of mileage using FreeRTOS+lwIP would presumably be able to pin point the failures in the machine generated code and feed that back to ST for corrections. The ST staff working on Cube do seem to be diligently going after the bugs, perhaps the community can do it's part by providing detailed bug reports, with suggested fixes. Presume you are configuring the software correctly and there's some issue with the tool. Provide your configuration files, versions, and generated source so the issue can be evaluated by people familiar with the tools, and in a position to recreate the failure mode.

[jarno]

Posted on April 17, 2014 at 09:19

I'm working on STM32F407 and to me it seems lwip sys_arch.c is not correctly wrapped to cmsis_os api, eg. my application hanged on lwip mem module calling sys_mutex_lock

u32_t sys_arch_sem_wait(sys_sem_t *sem, u32_t timeout) {   ... } void sys_mutex_lock(sys_mutex_t *mutex) {     sys_arch_sem_wait(*mutex, 0); } i'm novice programming with c, especially with pointers, but above lines of code looks wrong to me, am i wrong?

[stm32cube-t]

Posted on April 17, 2014 at 10:55

Hello Angelo,

Can you please send us the STM32CubeMX .ioc file corresponding to your configuration? Note STM32Cube uses LwIP version 1.4.1 and FreeRTOS v7.6.0. How come you're mentionning different versions? In the STM32Cube Firmware package you have project examples available for a set of ST boards. Which toolchain are you using? Thanks for your feedback.

[abrous3d]

Posted on April 17, 2014 at 22:19

Hello,

What I said is that my board is tested and it is working perfectly with another, non-Cube generated firmware with FreeRTOS 6.1.0 and Lwip 1.3.2. I played a little bit more with the configuration changing the clock source to HSE and external crystal and NVIC priorities (Systick -> preemption 15 and Ethernet global int to 6). The hard fault problem suddenly disappeared but now I have exactly the same issue with jkatajai above. The app hangs on lwip mem module calling sys_mutex_lock in configASSERT(pxQueue). Call stack is as follows : xQueueGenericReceive sys_arch_sem_wait mem_malloc pbuf_alloc etharp_raw etharp_request StartThread prvTaskExitError Find attached the configuration file. Thanks for your help ________________ Attachments : CubeTest2.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HzNn&d=%2Fa%2F0X0000000bMH%2FdFlj71iQVlz3PLgZXs1aP5g.MfexWgkGh.5vlN3un.s&asPdf=false

[abrous3d]

Posted on April 18, 2014 at 17:07

Probably this is a bug:

In  sys_arch.c. void sys_mutex_lock(sys_mutex_t *mutex) {     sys_arch_sem_wait( *mutex, 0); } It should be : void sys_mutex_lock(sys_mutex_t *mutex) {     sys_arch_sem_wait((sys_mutex_t *)mutex, 0); } It seems to work just fine now.

[Oussema Hajjem_O]

Posted on April 18, 2014 at 18:42Hi Angelo,I think that the allocated heap size for FreeRTOS  is not enough,try to increase the configTOTAL_HEAP_SIZE define in your FreeRTOSConfig.h fileThanks and regards

[jarno]

Posted on April 18, 2014 at 21:19

scanned through stm32cube examples and found definition on lwpipopts.h not present at the mx gui:

/* USER CODE BEGIN 1 */ #define LWIP_COMPAT_MUTEX               1 /* USER CODE END 1 */ after setting ETH priorities, modified priority group (which btw won't stay between cube mx sessions) on NVIC i finally got my app working but after adding only USART6 faced another problems with RCC latency changed from 5 to 0 (RCC definitons not changed).