DFSDM on DMA mode initialization issues on MP1.M4 Core

[Vicente Inostroza]

Hi All,

I've been running into an issue when trying to activate and run the DFSDM peripheral for the M4 Core to sample a single digital Mic:

• Source code and device tree generated using STMCubeIDE V1.1.10. The compiled device tree is loaded into the image running in the A7 core of the unit being used for testing.
• DFSDM1 Clock Configured using:

System clock (208.87793 MHz)

Divider 104 for DFSDM Clk -> ~2 MHz

Fosr: 125 samples -> Sampling frec of ~16 kHz

Channel 5 being used for regular conversions on Filter 0, set in Continuous Mode and Software Trigger

• The DFSDM application code was coded based on the STM32L4 - Hands-on DFSDM Tutorial, and was successfully run on a F412ZG Nucleo using a MP34DT05 coupon board to provide the microphone.
• This application was then ported to an MP1.M4 project targetting the DK2 Eval board.
• After calling HAL_DFSDM_FilterRegularStart_DMA(), the regular half and full conversion callbacks that will be used to process the samples, HAL_DFSDM_FilterRegConvHalfCpltCallback() and HAL_DFSDM_FilterRegConvCpltCallback(), are not being called at any point.
• It was verified on scope that the DFSDM clock is being output to the Microphone at the configured frequency.
• Debugging the code it was noted that in SystemClockConfig() the HAL_RCC_OscConfig() call is returning error when trying to start the HSE. However, this does not seem to affect the rest of the code, since the DFSDM clock has the correct frequency being derived from the System Clock.
• The IRQ Handlers for DMA2_Stream0 and DFSDM_FLT exist.

[PatrickF]

Hello,

depend on the way you debug your system.

If you use 'Production mode' (i.e. Linux started from Flash, M4 code loaded thru SSH), then most of the high-level RCC settings (HSE, PLL1/2, etc..) are protected and only under TF-A/uBoot/Linux Device Tree control. This is the nominal mode to be used in your final product.

If you use 'Engineering mode' (i.e. BOOT[2:0] = 0b100, Linux is not started, M4 code loaded thru JTAG/SWD), then the RCC is 'open' for M4 access and you got full control of clock seetings. Notice that this is only during development phase and all related code should be conditionned at compilation time or run time using "if(IS_ENGINEERING_BOOT_MODE())"

Please have a look on STM32CubeMP1 examples which work in both debug environments.

[Olivier GALLIEN]

Hi @Vicente Inostroza​ 

Above information given by @PatrickF​  and more are details here :

https://wiki.st.com/stm32mpu/wiki/STM32CubeMP1_development_guidelines

Hope it help

Olivier