Strange problem with I2C and timers

[Ivan Raykov]

Posted on May 04, 2018 at 09:05

Hi,

I have a board with STM32F030K6 and an sensor wired on I2C. When using the sensor in polling mode (no interrupts) everything is working fine and i am able to read data and send it trough UART.

Problem starts when I want to use a timer to generate a delay, because sensor need 20-30 minutes to stabilize readings.

I am trying to use TIM14, which is independent timer, but when it is on, and counting, the I2C transaction fail and i gent an error response from the sensor.

If I disable the timer, everything is working fine.

Can anyone help?

#i2c-sensor

[Ivan Raykov]

Posted on May 04, 2018 at 09:15

One more thing, when the code is run step by step, everything is running fine, when it is ran directly it glitches in forever loop.

[waclawek.jan]

Posted on May 06, 2018 at 12:33

I don't think there's any hardware reason for the behaviour you are describing.

the I2C transaction fail

How?

it glitches in forever loop.

What does this exactly mean?

JW

[AvaTar]

Posted on May 08, 2018 at 09:04

... and i am able to read data and send it trough UART.

Sounds like you are sending synchronously from within the interrupt handler routine.

[Ivan Raykov]

Posted on May 08, 2018 at 07:08

Hi,

so far i found that when interrupt occurs and I2C transaction is going on, dataflow from I2C is changed. If i disable interrupts before I2C transactions, and enable them after all transactions are completed, there is no problem, but if a interrupt is triggered during an I2C transaction - the data read from the I2C bus does not correspond to the actual data.

[waclawek.jan]

Posted on May 08, 2018 at 07:45

Then there's something in the interrupts which either interferes with the hardware related to I2C (e.g. GPIO register writes) or with the software handling I2C (especially if you use 'libraries').

JW

[Ivan Raykov]

Posted on May 08, 2018 at 09:18

@AvaTar - I am suing UART as a Multiprocessor Comm, set from the CubeMX. All of the functions i use are from CubeMX, but i cant find in which mode it is setting the processor, sync or async. In advance i will need to turn the UART communication in Modbus protocol.

Waclawek.Jan

‌ I am using the HAL libraries from the CubeMX, i guess there is something there, but i cannot find it, since the code is running smoothly when executed step-by-step. One more thing i have noticed, it actually reads I2C, but the data read is stored in a wrong location, maybe when the ISR gets back, it writes to wrong address?

[AvaTar]

Posted on May 08, 2018 at 09:32

@AvaTar  -  I am suing UART as a Multiprocessor Comm, set from the CubeMX. All of the functions i use are from CubeMX, but i cant find in which mode it is setting the processor, sync or async. In advance i will need to turn the UART communication in Modbus protocol.

I mean, you probably call a 'UART_Send()' function (however it is actually named in Cube) from within the interrupt handler, that only returns if sending all characters has finished. This used to be called 'synchronous'.

The UART send probably takes longer than two I2C bytes, thus you loose data with your equal-priorized interrupts.

So far my guess of your code.

[Ivan Raykov]

Posted on May 08, 2018 at 11:20

Actually there are separate UART_transmit functions, one with interrupt, other without. I am using the one without. The UART is not a problem, because it is called when all necessary data is collected over the I2C, so it wont influence the I2C.

The problem is the timer interrupt which is somehow influencing the I2C. It is independent timer, but maybe the library from the CubeMX have some issues with it.

[AvaTar]

Posted on May 08, 2018 at 11:32

You did not present any code, so I was guessing.

The problem is the timer interrupt which is somehow influencing the I2C.

Probably the same is true for the timer interrupt. If it's priority is equal or higher than the I2C interrupt, it can block enough to cause data loss. Check what you do in the interrupt, perhaps you can 'outsource' time-consuming operations.

... but maybe the library from the CubeMX have some issues with it.

Checking the CubeMX bug reports e.g. here in this forum, you can definitely drop the 'maybe' ...