STM32F4 I2c1 and USART1 (and USART6) conflict

[Bob jenkins]

Posted on October 14, 2017 at 19:32

I have an STM32F446RE Nucleo board. 

I am using I2C1 in interrupt (not DMA) mode, to continuously read data from an MPU9250 accelerometer/magnetometer/gyroscope board. I also use the USART1 to read logs with my laptop (using FTDI adapter) and to write some text commands to the STM32, that I read in a DMA mode.

The problem is that, occasionally, after I write into usart1 from a pc, a function HAL_I2C_Mem_Read_IT, that is supposed to read data from the MPU9250, returns error HAL_TIMEOUT. This doesn't happen always, in fact, this is a rare event. But I can't figure out why that might happen, how are I2C and USART related?

After I checked in CubeMX, USART1 pins, that I use, can be assigned to I2C1 as well (although they are assigned to USART1, and I2C1 uses different pair of pins). Just to be safe, I tried to use USART6 instead of USART1. And after a couple of tens of 'commands' that I sent via USART from my PC, I got this error HAL_TIMEOUT once again.

Why might that happen?

Thanks for your replies!

#stm32-stm32f4 #hal #i2c-and-uart

[Tesla DeLorean]

Posted on October 14, 2017 at 19:39

The peripherals should all function fine. Data loss in HAL tends to occur due to blocking, and inappropriate interrupt preemption/priority levels.

Callbacks occur under interrupt context, what you do in a callback should be considered and quick. Avoid any polled activity with USART, etc, that might take micro or milli-seconds to complete.

Buffer any data for the USART, and manage outside the callbacks for other peripherals.

[Bob jenkins]

Posted on October 15, 2017 at 00:13

Thanks Clive. I now moved processing of the data to the main infinite loop, and in the USART DMA IDLE interrupt callback I am just copying received data into another array. I suspect sscanf(), that I was using in the interrupt handler to fish out float numbers, could take too much time to execute even on STM32F4, causing i2c timeouts. Just a guess. (could it?).

[Tesla DeLorean]

Posted on October 15, 2017 at 02:07

I process GPS and modem transactions in worker threads.

[S.Ma]

Posted on October 15, 2017 at 11:21

Here, the data flow which can't be waited for by STM32 is the USART RX. The I2C being a master, transfer can be slow (unless there are MEMs interrupts which are present and not described). Usually, what runs in interrupt must be the minimum necessary task. What can be processed later should. Then, look at your data flow. For simple implementation, plumb your data flow through SW FIFO with the main loop, and use flags (set by interrupt, cleared by main loop) to handshake one way of the other.