Posted on April 24, 2014 at 04:50Greetings all,
I have a couple of problems with STM32CubeMX-V1.1.0 with the following options:
* STM32F439
* FreeRTOS
* LwIP
The first problem is a bug in the sys_mutex_lock function which is generated as:
void sys_mutex_lock(sys_mutex_t *mutex)
{
sys_arch_sem_wait(*mutex, 0);
}
It's calling the sys_arch_sem_wait function which has a prototype of:
u32_t sys_arch_sem_wait(sys_sem_t *sem, u32_t timeout)
As can be seen here; both sys_mutex_lock and sys_arch_sem_wait both expect to receive a 'sys_mutex_t*'; however sys_mutex_lock dereferences the pointer rather than passing it across correctly. The correct implementation of sys_mutex_lock is:
void sys_mutex_lock(sys_mutex_t *mutex)
{
sys_arch_sem_wait(mutex, 0);
}
The second problem is with configuring LwIP to disable DHCP and entering a static IP address in the LWIP Configuration dialog. The IP_ADDRESS value will only accept three digit IP addresses - for example ''010.001.101.099'' (you can't remove the zeros). It then turns around and pastes these values directly into the generated code. So lwip.c ends up with the following:
void MX_LWIP_Init(void)
{
IP_ADDRESS[0] = 010;
IP_ADDRESS[1] = 001;
IP_ADDRESS[2] = 101;
IP_ADDRESS[3] = 099;
Leading zeros in C result in the value being interpreted as OCTAL instead of decimal. This IP address is actually ''8.1.101.<syntax error>'' - a syntax error because 099 is not a legal octal constant. It's not actually possible to enter the value 99 because even if you try pre-convert to OCTAL you find that OCTAL(99) = 143, and trying to enter this in the field results in having no leading zeros so the number is interpreted as decimal 143.
Other than these minor items I'm highly impressed with the ease of the tool to get projects started. Keep up the good work!
- Malcolm
#stm32cubemx-lwip-bug
