Constructing an I2C causes the next I2C operation to fail.

[multiplemonomials]

Description of defect

I have been upgrading some Mbed 2 code to Mbed OS 6, and have run into some issues with I2C drivers. Specifically, if multiple
I2C objects were created representing the same physical bus, then transactions would sometimes fail. I've attached an example program that demonstrates the issue.

I'm not entirely sure what's causing it, but it seems to be related to a bad interaction between the recover() function and the LPC1768's I2C peripheral. If I comment out the call to recover() in the I2C constructor, everything seems to work normally. And when I checked with the debugger, the failing I2C transaction seems to occur because the HAL i2c_start() function is reading a bad status value from chip registers. I'm not exactly an expert on LPC1768 I2C though so I'm not exactly sure how recover() is causing this problem.

Target(s) affected by this defect ?

LPC1768

Toolchain(s) (name and version) displaying this defect ?

GCC_ARM

What version of Mbed-os are you using (tag or sha) ?

mbed-os-6.5.0

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

mbed-cmake v1.4.2, but it should behave identically to mbed-cli.

How is this defect reproduced ?

I made a simple program that demonstrates the issue. All you need is to connect an LPC1768 to any valid I2C peripheral. Then fill in the correct pins and address for the peripheral in the #defines.

//
// Demonstration of Mbed 6 I2C bug
//

#include <mbed.h>

#define I2C_PART_ADDR 0xA0 // 8 bit address
#define SDA P0_27
#define SCL P0_28

int main()
{
	I2C i2c1(SDA, SCL);

	int retval1 = i2c1.write(I2C_PART_ADDR, nullptr, 0);

	printf("Retval of first write with i2c1: %d\n", retval1);

	I2C i2c2(SDA, SCL);

	retval1 = i2c1.write(I2C_PART_ADDR, nullptr, 0);
	int retval2 = i2c2.write(I2C_PART_ADDR, nullptr, 0);

	printf("Retval of second write with i2c1: %d\n", retval1);
	printf("Retval of second write with i2c2: %d\n", retval2);

	retval1 = i2c1.write(I2C_PART_ADDR, nullptr, 0);
	retval2 = i2c2.write(I2C_PART_ADDR, nullptr, 0);

	printf("Retval of third write with i2c1: %d\n", retval1);
	printf("Retval of third write with i2c2: %d\n", retval2);

	while(true) {}

	return 0;
}

On my LPC1768, this outputs:

Retval of first write with i2c1: 0
Retval of second write with i2c1: 1
Retval of second write with i2c2: 0
Retval of third write with i2c1: 0
Retval of third write with i2c2: 0

Clearly, constructing a second I2C should not cause a write that previously succeeded to fail, so it's a bug that the second line has a 1 retval.

If I comment out this line and rerun the test, all I2C writes succeed.

[ciarmcom]

Thank you for raising this detailed GitHub issue. I am now notifying our internal issue triagers.
Internal Jira reference: https://jira.arm.com/browse/IOTOSM-2930

[ithinuel]

Hello, this use case is not expected to work.
Only have at most 1 C++ per peripheral at a time, i2c1 must be destroyed before i2c2 is instantiated.
i2c1 and i2c2 are competing for the ownership of the same hardware peripheral. Mbed does not provide any mechanism to solve such issue.

The appropriate solution is to instantiate your bus once and share a reference (or a smart pointer) to that instance across your application.

[multiplemonomials]

Hmm, I got the opposite answer when I asked on the forums here. And the I2C docs don't say either way.

I feel like it really should support this usage because it's the only sane way to handle multiple devices on the same bus running at different frequencies. If each uses their own I2C then the library will take care of changing the frequency for each operation, whereas if all of them share an instance each driver class has to reset the frequency for each and every operation. The situation is even worse for SPI, where not just the frequency but also the mode and CS pin is different for each driver. Plus, using it in this way has worked on every device I've ever tried except LPC1768 running Mbed 6.

[multiplemonomials]

@ithinuel Also, note that the I2C driver includes the aquire() function, which seems to try to deal with exactly this case where multiple I2C objects are sharing hardware.

[multiplemonomials]

(That said, it seems weird that I2C::start() doesn't call aquire like the multi-byte functions do)

[ithinuel]

Indeed, there are some inconsistencies in the I2C and SPI driver.
We attempted to address that as part of the I²C and SPI over haul work.
But because of how a breaking change it would be, the path to solve them is longer than we'd like it to be.

[idea--list]

Wow...
I2C and SPI being probably the 2 most often used buses and because of some morons can not think, they prepend people will never use more devices on the same physical bus...
Sure! MCUs tend to have dozens of SPI/I2C pins and all those are lead out on each of our boards. Yeah!

Does it really mean we insist to "proof of concept" quality code in OS releases intended for production, just because fixing it would break something that does not seem to be broken at first sight (but is broken in an occult way which is the worst kind of bugs)?

[donatieng]

Hi @idea--list,

I can understand you feel strongly about the above issue but please refrain from using abusive language. We thrive to make Mbed a safe and welcoming community and therefore personal attacks have no place here. Hope we can re-focus the discussion on the matter at hand, and keep the debate constructive.

Thank you, Don

[0xc0170]

Back to the issue as I reviewed the code today.

I2c and Spi objects provide acquire() method to take care of ownership, it's simple ownership = one owner at the time.
The issue reported here is related to lpc1768 and recover method - not about ownership (if we got a issue there, it should be a separate issue).
Another issue is i2c start does not invoke acquire . Also stop method does not. That should be fixed, I'll send PR fixing it.
@multiplemonomials does recover for lpc1768 return 0 or busy error?

[idea--list]

Hi @donatieng ,

personal attacks have no place here

As i do not know anyone who might be involved, i am not sure if i could have personally attacked anyone by not naming anyone.
I understand the the Mbed community thrives to make Mbed OS a good framework. Well... i also thrive learning the framework for a long time now and i find myself facing bugs in almost anything i touch... sometimes i find the solution how to circumvent them, other times not.

And then i just find a bug report about I2C and SPI implementation (cornerstone features) being buggy on LPC1768 (on which Mbed started it's journey). This bug is comparable to a situation where you try to offer a house that has no doors, just the opening for that and you tell installing the doors would be breaking, so we postpone the fix for a long time. While on the other hand breaking changes may have happened with minor features where it did not seem to have such a postponing effect.
And actually if the release notes tells that the issue has been fixed and how should one port their code in case of upgrading their OS version, well then nothing would remain broken. 😉

@0xc0170 Thanks for taking effective action as always!