HAL I2C Error

[RichardB01]

Forum reference: https://www.stm32duino.com/viewtopic.php?f=7&t=928

Chip: STM32L452RE

Describe the bug
Trying to read current voltages for for long periods of time results in an assertion being thrown by the HAL I2C library. There is more information in the forum post, additionally the F3 (?) series has an eratta to do with the HAL I2C but i'm not sure whether this applies to the L452RE.

Screenshots
Here is a call stack of the HAL I2C assertion failing.

Desktop (please complete the following information):

• Windows 10
• 1.8.13
• 1.9.0
• STM32CubeProgrammer SWD

Board (please complete the following information):

• Name: STM32L452RE

Additional context
Add any other context about the problem here.

[RichardB01]

Just to clarify, even if the sketch is changed so that the voltage read is retrieved slower, for example, every 30 seconds it still breaks. It just takes longer for the error to occur.

[RichardB01]

It looks like the HAL I2C works fine on its own but when combined with other libraries it fails

[RichardB01]

i have been running the INA266 library for around 15 hours now, it doesn't seem to be the library alone but some other part of the HAL code breaking it

[ABOSTM]

Hi @Bambofy,
I am a bit confused with your description:

Trying to read current voltages for for long periods of time results in an assertion

Can you be more precise:
how long ?
It is always the same time on several run ?

... additionally the F3 (?) series has an errata to do with the HAL I2C but i'm not sure whether this applies to the L452RE.

There is an errata sheet for each chip within F3 serie, so I don't know what you refer to. Also if I take for example stm32f303xbc errata sheet, there are several issues related to I2C, so Is don't know what you refer to.
Whatever, the best is to look directly at STM32L452 errata sheet:
https://www.st.com/resource/en/errata_sheet/dm00345114-stm32l452xx-device-errata-stmicroelectronics.pdf
And finally, as you have assert failure, it looks like you have an software issue and not an hardware issue.

In the forum you said that assert failure is at line 3210,
but looking at the call stack it is clearly at line 3196 !!

It looks like the HAL I2C works fine on its own but when combined with other libraries it fails

What do you mean by HAL I2C is working fine on its own? did you test with other I2C devices? which ones?
What do you mean by "when combined with other libraries it fails" ? did you test other library than INA260 ? which ones?

i have been running the INA266 library for around 15 hours now, it doesn't seem to be the library alone but some other part of the HAL code breaking it

I guess you mean INA260.
I don't understand how you can run library alone ?

I don't understand why you are talking about I2C BUSY state:
there is an assert that has nothing to do with Busy state.

"Just to clarify, even if the sketch is changed so that the voltage read is retrieved slower, for example, every 30 seconds it still breaks. It just takes longer for the error to occur."
30 secondes compare to what ? I don't have your original sketch.

Now, let's analyse the assert failure:
Line 3196:
if ((hi2c->PreviousState == I2C_STATE_MASTER_BUSY_TX) && (IS_I2C_TRANSFER_OTHER_OPTIONS_REQUEST(XferOptions) == 0))
the assert correspond to the check that parameter XferOptions is valid:

#define IS_I2C_TRANSFER_OTHER_OPTIONS_REQUEST(REQUEST) (((REQUEST) == I2C_OTHER_FRAME)     || \
		((REQUEST) == I2C_OTHER_AND_LAST_FRAME))

Can you give us the value of XferOptions when assert fails ?
Is it always the same value when it fails ?

Going up in the callstack, XferOptions is set in TwoWire::endTransmission()

  if (sendStop == 0) {
    _i2c.handle.XferOptions = I2C_OTHER_FRAME ;
  } else {
    _i2c.handle.XferOptions = I2C_OTHER_AND_LAST_FRAME;
  }

So normally XferOptions cannot be different from I2C_OTHER_FRAME or I2C_OTHER_AND_LAST_FRAME, and assert should not be failed ... except if there is some memory corruption.

Can you make a direct relation between frequency of read, and time to get the error ?

Can you reproduce this issue, with a minimal sketch that only reads value in loop (without any other action) ?
And can you share your sketch (the minimal one).
Note: there is an open issue on the library about memory leak that could be your issue as memory leak can lead to memory corruption
adafruit/Adafruit_INA260#5

[RichardB01]

Hi @ABOSTM

Sorry for the vauge reports this is because i'm not sure what is going wrong with the software.

I have started a thread on the forums here https://www.stm32duino.com/viewtopic.php?f=7&t=928&p=6141#p6141 The latest post notes the line numbers which the assertion fails are happening at.

When i use the ina260_test.ino sketch provided by adafruit it works fine. But when i use the same code in my larger program, it throws the assert listed above.

Through experimenting it looks as though it has something to do with the frequency of the readVoltage() function being called. If i reduce the number of calls to the readBus() function it seems to work but i have no way of properly checking whether this fix is an actual fix, or i am just delaying the issue.

Cheers!

[ABOSTM]

Hi @Bambofy,
You didn't answer to all the questions I raised.
Whatever, as there is no issue on adafruit sketch, but issue when you used it on larger program,
. . . it seems there is no issue in the stm32duino/HAL, but issue in the larger program you made around.
I stick to my analysis: there should be an memory corruption. By the way it could explain that assert fail happens at different locations.
So you need to dig into the larger program to check what can cause the memory corruption (eventually memory leakage).
Maybe restart from the adafruit sketch and add step by step your program to check what cause the memory corruption.

[fpistm]

Hi @Bambofy
I close this issue as it seems more related to your larger program than the HAL I2C.
If you can reproduce with a simple sketch then we will reopen this issue.