STM32F1 I2C with DMA, processor stays busy during read/write operation

[gvuyk07]

Posted on April 29, 2016 at 05:08

Everything is working, just not as I thought it should be. As the logic analyzer shows below, the main loop is interrupted for almost the same amount of time the I2C operation takes.

Notes: - I'm using Cube generated HAL library - First and last thing on the main loop is to toggle a pin, that's what you see on the analyzer's ''Main loop'' channel (High at the beginning, low at the end) - Same thing for the ''DMA complete'' channel, a pin is pulsed for the duration of the HAL_I2C_MemRxCpltCallback interrupt routine I tracked down the portion of code causing this busy time to this private function I2C_RequestMemoryRead  it even receives a timeout as a parameter (35ms defined by the library) Looking at the comments inside this function, gives me the impression that there's some bit banging going on? I thought the dedicated I2C module was supposed to deal with this stuff Where am I wrong?

[franck23]

Posted on April 29, 2016 at 11:04

Hi Zawyer,

It's a bit difficult to see the I2C data on your picture, so what I guess is you have:AddW + 1 Data + AddR + 6 byte of dataI2C addresses cannot be sent by the DMA, sot he 3 first bytes sent (AddW + Data + AddR) are sent by flag polling.After that your 6 bytes of data are loaded to the DMA buffer and your firmware is freed.This would be your 267us main loop interruption.If your slave do some clock stretching, it can take more time. It is maybe what happen for the first 3 bytes: the SCL line is kept low for a while.F.

[gvuyk07]

Posted on May 02, 2016 at 06:27

Hi

Thanks, I guess I'll be discarding DMA and going just with interrupts instead Also looks like I'll be discarding Cube HAL library too, I don't think that clock stretching you mention for the first 3 bytes is caused by the slave device I've seen other people achieve way better speeds with this same slave, using the standard peripheral lib, didn't go deep in their code yet