Program freeze in Hal_delay() but systick seems OK

jmf1 · ‎2016-10-20

Posted on October 20, 2016 at 22:07

Hello,

I work on an USB audio with async feedback application on Stm32F4 discovery. I had several prototypes working, but the last doesn't. The code gets blocked in an endless loop inside a Hal_delay(5) call. Looking on internet, it looks like a potential interrupt priority problem between systick and something else.

Systick seems correctly configured but the default calls and a HAL_NVIC_SetPriority(SysTick_IRQn, 0, 0);

My code uses the Stm32F4 discovery BSP libraries. The freeze call sequence is:

HAL_Delay() at stm32f4xx_hal.c:342 0x8000e5e

AUDIO_IO_Init() at stm32f4_discovery.c:648 0x800076c

cs43l22_ReadID() at cs43l22.c:234 0x8000350

BSP_AUDIO_OUT_Init() at stm32f4_discovery_audio.c:254 0x80009b2

Audio_Init() at usbd_audio_if.c:162 0x800464e

USBD_AUDIO_Init() at usbd_audio.c:435 0x80041da

Studying the code I saw that the I2C interrupt used to control the audio CODEC (CS43122) seems to also have the highest priority... But this seems to work in another example I adapted from the CubeF4 proposed ones:

STM32Cube_FW_F4_V1.13.0\Projects\STM324x9I_EVAL\Applications\USB_Device\AUDIO_Standalone

Any help welcome about possible source of the bug or ways to identify it. Full code is available in

https://github.com/jmf13/USB_Async_DAC/tree/RingBufferInUSBD

Best regards,

JM

jmf1 · ‎2016-10-20

Posted on October 21, 2016 at 07:47

If I move the call to BSP_AUDIO_OUT_Init() after the intialization sequence of the USBDevice, then there is no freeze and the BSP_AUDIO_OUT_Init() performs the complete initialization. So it seems related to the nesting of this call inside the USBD_Audio process. However, it is the way it is done in the ST working example.

I don't understand...

JM