32F4 problem with latest DMA files
Posted: Tue Sep 01, 2015 2:18 pm
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.
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.