Skip to main content
Ivan Raykov
Associate
May 4, 2018
Question

Strange problem with I2C and timers

  • May 4, 2018
  • 3 replies
  • 2436 views
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
This topic has been closed for replies.

3 replies

Ivan Raykov
Associate
May 4, 2018
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
Super User
May 6, 2018
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

Ivan Raykov
Associate
May 8, 2018
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
Super User
May 8, 2018
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

AvaTar
Senior III
May 8, 2018
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
Associate
May 8, 2018
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
Senior III
May 8, 2018
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.