Page 1 of 1

32F4 problem with latest DMA files

Posted: Tue Sep 01, 2015 2:18 pm
by steved
Just encountered a strange problem on the 32F4.

My application is managing a fairly busy I2C slave port (using the code posted elsewhere, which is very largely down to Brent Roman).

With the DMA files as per the 3.0.1 release (i.e. stm32_dma.h and stm32_dma.c) in the 32F4-specific directory, my application runs OK.

Having updated the repository to the latest, where the DMA files are in the LLD/DMAv2 directory, and cleaned up the files no longer required, my I2C comms seizes up, apparently after the first transaction. Other parts of the application continue to run OK.

On a quick look, the two source code variations should achieve identical code output - all the differences are in #defines which should evaluate the same. And a lot of numeric values are explicitly declared as 'unsigned' with the 'U' suffix.

Not dug too deeply yet; wondered if anyone else had seen something similar.

Re: 32F4 problem with latest DMA files

Posted: Tue Sep 01, 2015 2:59 pm
by Giovanni
I haven't tried I2C (lack of HW) but SPI and ADC seems to work correctly.

The same DMA driver is used by the F7 port, I2C is one of the things I am going to test next, however on the F7 there is an I2Cv2.

Giovanni

Re: 32F4 problem with latest DMA files

Posted: Wed Sep 02, 2015 8:52 am
by steved
Tracked the problem down to the dmaStreamDisable() macro in stm32_dma.h. The 'original' clears all the interrupt flags. The 'new' version doesn't.

Could of course be a problem in the slave I2C driver - having received a message it spends rather longer than it probably ought to in an ISR processing the received message and generating the reply. Or maybe a timing race.

Re: 32F4 problem with latest DMA files

Posted: Wed Sep 02, 2015 9:13 am
by Giovanni
Thanks, I thought is cleared all flags, just the sequence of operations is different. I will restore the original code anyway.

Giovanni