Posted by spflanze on 2016-05-17 05:33

The processor is an STM32F373. This an STM32CubeMX 4.14 generated project with FREERTOS enabled, and the SysTick TImebase Source.

Calls to: HAL_Delay(50), vTaskDelay(50), and osDelay(50) hang. This hang is in the function vPortRaiseBASEPRI() which, as I can see in the disassembly window, has as its last instruction an infinite loop.

This is the disassembly I see for that function:

215                                       	__asm volatile
0800a564: 0x4ff05003 ...eGenericReceive+8   mov.w   r3, #80 ; 0x50
0800a568: 0x83f31188 ...GenericReceive+12   msr     BASEPRI, r3
0800a56c: 0xbff36f8f ...GenericReceive+16   isb     sy
0800a570: 0xbff34f8f ...GenericReceive+20   dsb     sy
0800a574: 0x0000fee7 ...GenericReceive+24   b.n     0x800a574 <xQueueGenericReceive+24>

215                                         __asm volatile

0800a564: 0x4ff05003 ...eGenericReceive+8   mov.w   r3, #80 ; 0x50

0800a568: 0x83f31188 ...GenericReceive+12   msr     BASEPRI, r3

0800a56c: 0xbff36f8f ...GenericReceive+16   isb     sy

0800a570: 0xbff34f8f ...GenericReceive+20   dsb     sy

0800a574: 0x0000fee7 ...GenericReceive+24   b.n     0x800a574 <xQueueGenericReceive+24>

The b.n instruction is an unconditional branch to itself. Was it meant to be this way? Or is this a bug? What can be done about it?

In Project => Properties => C/C++ Build (tree) => Settings => Tool Settings (tab)
The compile’s Optimize for Debug (-Og) option was selected.
Place the function in their own section was checked.
Place the data in their own secions was not checked.