AnsweredAssumed Answered

Program freeze in Hal_delay() but systick seems OK

Question asked by fourneron.jean_marc on Oct 20, 2016
Latest reply on Oct 21, 2016 by fourneron.jean_marc
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

Outcomes