STM32F769I-DISCO: Demonstration software: Audio recorder not working

[JB2500]

Posted on February 15, 2017 at 15:11

I've not been able to get the Audio Recorder in the demonstration software working. I'm using V1.2 of the software, as supplied with Cube V1.6.0.

Test:

• Compile Demo V1.2 in Cube V1.6.0 using Eclipse 4.6.2 / Ac6 SystemWorkbench.
• Program the board with the software. (The first time I did this I used the STM32 ST-LINK Utility with the MX25L512G_STM32F769I-DISCO external loader so as to program both the software and the quad SPI flash images data. Thereafter, I programmed the board directly from Eclipse by starting an OpenOCD debugging session).
• Insert a USB drive that is known to work with the Audio Player. (I've found that not all USB drives are compatible).
• Reboot the board.
• Click 'Audio Recorder'.
• Click the circular Red button.

When I do this, the red button goes blue and the software hangs (including the UI and the USB driver) until the board is rebooted.

I've tried debugging the recorder and found that:

• HAL_DFSDM_FilterRegularStart_DMA at line 1535 of stm32f7xx_hal_dfsdm.c is called twice; each time calling HAL_DMA_Start_IT().
• HAL_DMA_IRQHandler() at line 753 of stm32f7xx_hal_dma.c is called and completes with no errors.
• HAL_DFSDM_FilterRegConvHalfCpltCallback() at line 1101 of stm32769i_discovery_audio.c is called re the top-right filter.
• If HAL_DMA_Start_IT() at line 1579 of stm32f7xx_hal_dfsdm.c is commented out, and hence the DMA is not started, then the software does not hang.
• When the software hangs, clicking 'Suspend' in the debugger causes execution to stop in Default_Handler of startup_stm32f769xx.s. According to the comment there, this means that an unexpected interrupt has occurred.

Ideas on any or all of the following would be most welcome:

• What might be wrong.
• How to proceed with debugging. In particular, if an unexpected interrupt has indeed occurred, how to find out more about it.
• How to report the problem to ST.

Cheers,

JB.

[Imen.D]

Posted on February 15, 2017 at 18:50

Hello,

Did you tried the ready example in the STM32CubeF7 firmware package and follow the instructions on the readme files?

STM32Cube_FW_F7_V1.6.0\Projects\STM32F769I-Discovery\Applications\Audio\Audio_playback_and_record

I suggest you to debug, localize where the code hangs and precise what do you have exactly as an error message.

You may refer to this

http://www.st.com/content/ccc/resource/technical/document/application_note/c7/2f/66/a5/cd/4c/4d/2a/DM00040802.pdf/files/DM00040802.pdf/jcr:content/translations/en.DM00040802.pdf

describing how to use the audio recording application, it maybe helpful.

Hope this helps you.

Regards

Imen

[JB2500]

Posted on February 15, 2017 at 19:23

Hi Imen.

I've previously tried compiling the Audio_playback_and_record standalone example and that works fine. However, I've not yet managed to learn anything from it that has helped with fixing the Demostration Software audio recorder.

I've studied AN3997, which incidently is for the F4 Discovery rather than F7, but it is not at an appropriate level of detail for the problem in hand.

I've cut the demonstration software down to just the audio recorder (to greatly reduce the built and programming time).

Then, by using the Default_Handler in http://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html, I've found that DMA 2 stream 4 does not have an interrupt handler. I'm currently looking into why this is.

JB.

[JB2500 · Accepted solution]

Posted on February 16, 2017 at 02:14

I've solved the problem. It was indeed because DMA 2 stream 4 did not have an interrupt handler. This was due to a combination of:

1. A bug in 'STM32Cube_FW_F7_V1.6.0\Drivers\BSP\STM32F769I-Discovery\stm32f769i_discovery_audio.h' of Cube V1.6.0.
2. An Eclipse build issue.

The Cube bug is in lines 191 to 193 of the above file. These lines specify DMA2_Stream0 but should instead specify DMA2_Stream4.

♯define AUDIO_DFSDMx_DMAx_TOP_LEFT_STREAM   DMA2_Stream0 /* JSB: Should be DMA2_Stream4 */
 
♯define AUDIO_DFSDMx_DMAx_TOP_LEFT_IRQ   DMA2_Stream0_IRQn /* JSB: Should be DMA2_Stream4_IRQn */
 
♯define AUDIO_DFSDMx_DMAx_TOP_LEFT_IRQHandler   DMA2_Stream0_IRQHandler
/* JSB: Should be DMA2_Stream4_IRQHandler*/
 

The result is consistent with the following three blocks of code (and works).

The Eclipse build issue was an odd one:

There are two versions of both stm32f769i_discovery_audio.h and stm32f769i_discovery_audio.c: one in the project and the other in '<Cube>/Drivers/BSP/STM32F769I-Discovery'.

Crucially, the version of stm32f769i_discovery_audio.h in the project does not have the above bug.

Somehow Eclipse was compiling stm32f769i_discovery_audio.c in the project with stm32f769i_discovery_audio.h in the project, but stm32f7xx_it.c in the project with stm32f769i_discovery_audio.h in '<Cube>/Drivers/BSP/STM32F769I-Discovery'.

As a result, stm32f769i_discovery_audio.c was producing DMA 2 stream 4 interrupts but stm32f7xx_it.c was handling DMA 2 stream 0 interrupts. DMA 2 Stream 4 interrupts were therefore not handled, resulting in the audio recorder hanging, which was the original problem.

Incidentally, if '<Cube>/Drivers/BSP/STM32F769I-Discovery/stm32f769i_discovery_audio.h' is used throughout, i.e. by both stm32f769i_discovery_audio.c and stm32f7xx_it.c, e.g. by renaming the version in the project to force the compiler to look further, then the Audio Recorder works again, despite the above header file bug. This is because DMA 2 stream 0 interrupts are then both produced and handled, even though they should be stream 4 ones. Nevertheless, that's not a good reason to stick with the bug, for obvious reasons. Therefore, it would be helpful for the bug to be fixed.

JB.

[Imen.D]

Posted on February 16, 2017 at 14:05

Hello

Bladen.John

,

Thanks for sharing your solution and feedback.

I will report internallythis issuefor checking and working andI will come back to you as soon as I have needed details.

Imen

[JB2500]

Posted on February 16, 2017 at 15:14

Thanks Imen.

In addition:

♯define AUDIO_DFSDMx_DMAx_LEFT_IRQ  DMA2_Stream0_IRQn
♯define AUDIO_DFSDMx_DMAx_RIGHT_IRQ DMA2_Stream5_IRQn
♯define AUDIO_DFSDM_DMAx_LEFT_IRQHandler DMA2_Stream0_IRQHandler
♯define AUDIO_DFSDM_DMAx_RIGHT_IRQHandler DMA2_Stream5_IRQHandler

should be:

♯define AUDIO_DFSDMx_DMAx_LEFT_IRQ DMA2_Stream4_IRQn
♯define AUDIO_DFSDMx_DMAx_RIGHT_IRQ DMA2_Stream5_IRQn
♯define AUDIO_DFSDM_DMAx_LEFT_IRQHandler DMA2_Stream4_IRQHandler
♯define AUDIO_DFSDM_DMAx_RIGHT_IRQHandler DMA2_Stream5_IRQHandler

in file '<,STM32Cube_FW_F7_V1.6.0\Drivers\BSP\STM32F769I_EVAL\stm32f769i_eval_audio.h'.

Please pass this on too.

Cheers,

JB.

[JB2500]

Posted on February 16, 2017 at 16:56

And there's a possible error here too, again in 'STM32Cube_FW_F7_V1.6.0\Drivers\BSP\STM32F769I-Discovery\stm32f769i_discovery_audio.h':

♯define AUDIO_DFSDMx_TOP_RIGHT_CHANNEL DFSDM_CHANNEL_0
♯define AUDIO_DFSDMx_TOP_LEFT_CHANNEL DFSDM_CHANNEL_1
♯define AUDIO_DFSDMx_BUTTOM_RIGHT_CHANNEL DFSDM_CHANNEL_4
♯define AUDIO_DFSDMx_BUTTOM_LEFT_CHANNEL DFSDM_CHANNEL_5

This should possibly be:

♯define AUDIO_DFSDMx_TOP_LEFT_CHANNEL DFSDM_CHANNEL_0
♯define AUDIO_DFSDMx_TOP_RIGHT_CHANNEL DFSDM_CHANNEL_1
♯define AUDIO_DFSDMx_BOTTOM_LEFT_CHANNEL DFSDM_CHANNEL_4
♯define AUDIO_DFSDMx_BOTTOM_RIGHT_CHANNEL DFSDM_CHANNEL_5

For consistency with Cube code elsewhere. This involves swapping channels 0 and 1, and swapping channels 4 and 5. I've not checked whether this is correct with the F769 Discovery board. FWIW, on the schematic the two top sensors connect to DFSDM_DATIN1, and the two bottom sensors connect to DFSDM_DATIN5. I've not investigated how these signals are used in the MCU.

Please pass this on too.

Cheers,

JB.