32F4 problem with latest DMA files

[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.

[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

[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.

[Giovanni]

Thanks, I thought is cleared all flags, just the sequence of operations is different. I will restore the original code anyway.

Giovanni