stm32f4 DMA1 stream3 I2S2 interference with USB?

[Jan Slavot�nek]

Posted on December 13, 2016 at 13:26

Hi guys! 

I will try to describe my problem conditions as thoroughly as i can. Thank you very much for reading through!

I need to implement similar project like stm's example on audio receive from microphone (audio playback and record). So i have setted up and implemented my own project with the same settings. (previously i made fully functional project where i use ADC to sample from electret microphone and save into .wav to my flash drive under FatFs msc class. I have sampled pretty fast 48kHz and data write to USB without any problem).

Now I have a following problem: I want to make exactly the same procedure as in audio example. I am using DM1 stream3 for transferring data from my I2S2 to circullar buffer. I use one buffer for PCM write (as in the example) and i transfer content of that buffer half by half. Problem occure when i need to write that very first chunk (half of buffer) of data using f_write USB on my flash drive under FatFs. 

During debugging, i can see, that actually write goes sucessfully. and after taht program returns to main (i handle data from the main wainting for volatile uint8_t flag being set from DMA when half of WrBuffer is ready.). Problem occurs right after when another DMA IRQ occures (first half of circullar DMA buffer ready). For debugging purpouse i light an orange LED on my discovery board inside DMA IRQ and turn it off when returns from IRQ handler. When stepping into IRQ Handler i can get into my 

'HAL_I2S_RxHalfCpltCallback'

and i see that i can sucessfully take my fresh data from half of the circullar buffer (the buffer has size 128 sizeof(uint16_t), so the half is exactly 64 uint16). Ok from there i feed the data into PDM filter

'PDM_Filter_64_LSB'

 (using the most recent PDMfilter library for CM4F). And here it is where my code stucks! 

If i stop data writing  from WrBuffer (stop f_writing to USB) program happily fill my WrBuffer all over again infinitelly. (This level works correctly when running without USB data writing). 

But when i perfromy only 1B write from independend buffer (just some dummy data) during I2S process running, the program stucks on PDM filter function ... 

when i hit 'pause' on my debugger after program seems to be stucked, it stops in disassembly on this line(

08007a10)

:08007a10: b.n 0x8007a10 <PDM_Filter_64_LSB+24>08007a12: nop 08007a14: lsrs r0, r4, &sharp208007a16: movs r0, &sharp0

Have no idea what that means. When i hit another 'step into' then program becomes unresponsive. 

Any ideas? 

Thanks Jan

PS: I will try to enclose my entire program including CubeMX file. It is CubeMX project + atollic truestudio project + all source code files. 

#program-stuck #usb-msc-fat #stm32f4-discovery-pdm-filter #i2s-dma

[Jan Slavot�nek]

Posted on December 13, 2016 at 13:30

I add one more observation: when i only record one full buffer of PCM converted data and then stop DMA, i am able to store this one chunk of data onto USB flash disc and i can even play it on my PC and it seems to be fine ...

[Jan Slavot�nek]

Posted on December 13, 2016 at 18:29

My recent theory is, that when the DMA IRQ occured, it was interrupted by some sort of USB interrupt request, or USB was interrupted by DMA and it resulted in failure. 

-> My conclusion is that i should remove all the code from DMA callbacks as i think it is just not healthy to make so much things (so muhc process time) in the IRQ ...Please can any stm official try to help me with my issue? I would higly appreciate help on that. Can you at least give me details about settings of USB + NVIC? I already have settings on I2S.  

[Jan Slavot�nek]

Posted on December 14, 2016 at 11:13

Hi guys!

Today i made further research. I implemented TIM5 for purpouse of measuring how much of processing time is consumed by what. So far, i have realised, that USB background process eats way too much processing time and what more i have realised, that in example app (audio playback and record) they avoid this background USB process (when recording or playback starts ... So i have did the same, but it still isnt enough. Program still stucks when I2S DMA IRQ occures and program never return from there.

Now i am doing only: processing data from I2S + performing f_write on USB. So next suspected is USB. I am gonna observe how much of processing time it takes, then i gonna measure how much of processing time it takes in the example. Mabye i should implement faster USB (right now i implement only USB_OTG_FS). 

Thanks for any ideas. 

EDIT: I have also observed PDM library filter function, it consumes really litle of processing time. Well it is something like 60k cycles (i am running 186MHz) so that is not so crucial - but i still doesnt like the fact, that it is called from interrupt.

EDIT2: f_write(); func takes only 2500 cycles to pass through. I assume that means it is definitaly not a polling method of putting data to USB. It must be handeled by IRQ or some kind of DMA. So that must be why my I2S DMA IRQ get stucked, because it is interrupted by something with higher priority, and during that recursion happens or smthing ...

:(

 

[Jan Slavot�nek]

Posted on December 14, 2016 at 12:17

Here is my NVIC table. But it doesnt matter what settings i make. I tried new approach: I got rid of subpriority, now i am using only preemption priority. I have tried SPI_DMA priority set to 0 and USB set to 1... AlsoUSB 0 and SPI_DMA 1. Doesnt matter.

Another Courious thing is: That when i put break point to part, where f_write is called, when i get there, i put another breakpoints to IRQ's and hit ''unpouse'' then i can observe that program goes into DMA IRQ (data from microphone ready), then program goes intoOTG_FS_IRQ , then i can see it goes back to DMA IRQ and it stucks here ... exactly in the PDM library.

I even made an experiment where i light up orange LED right before program enters into PDM filter function, and turn off right after program returns from PDM filter function returns. It always get stucked with my orange LED lighting. That means program really get stucked inside that function that is part of STMs static library.

Now please can anyone tell me, how this pdm func can be influenced by fatfs write to USB? I have no clue ...

Also, why STM can not provide us with .c file for the PDM library?!!!! Then i could easily build it on my own with whatever HW/SW floating point settings i want and i could observe my program stucking inside that library! But with that static library it is not possible!

@

FTITI.Walid

please could you or some of your colleagues give me any support on my issue?