i2c.write();/i2c.read();

[lionyhw]

i2c.write();/i2c.read();
In the version of microbit V2 is unstable, it will sometimes prompt OS error 19. The same hardware and code are stable in microbit v1.

ds1307.py.zip

I use this file to test.This is an RTC module.

[microbit-carlos]

Thanks for the report @lionyhw. Will you be able to provide the smallest possible section of code to reproduce the issue? It's really hard to debug otherwise.
And does the code need a DS1307 device to work?

[lionyhw]

The API of I2C cannot work without connecting I2C device.
I know it's hard to test, but I can't reproduce the I2C problem in other situations. Do you have any good ideas?
What is OS error 19?

[microbit-carlos]

Yes, debugging with I2C will always be hard, specially if we don't have the device, but we can try to simplify the code it as much as possible to see if we can figure which part might be triggering the problem, or perhaps replicate it with a different device.

The best first step would be if you could create the smallest script possible that shows the issue.

What is OS error 19?

How did the error appear? Is it an exception scrolling on the display? In that case if you connect to the REPL and reset the micro:bit the full error message should show up.

Or does the error code show up in the display with a :( face?

[jaustin]

I think it is worth looking at this in light of lancaster-university/codal-microbit-v2#8

[jaustin]

@dpgeorge can you please let us know what OS error 19 is? Could this be MicroPython related rather than CODAL?

[dpgeorge]

The ds1307.py driver above does only simple reads/writes, like this:

i2c.write(DS1307_I2C_ADDRESS, <data>)
data = i2c.read(DS1307_I2C_ADDRESS, <n>)

These read/write methods are very thin wrappers around the CODAL uBit.i2c.write() and uBit.i2c.read() methods.

The OSError(19) means ENODEV (no such device), and in this case is just a generic error message raised by MicroPython because the CODAL method returned an error (did not return DEVICE_OK).

Looking at the CODAL source, it seems the only error code it can return is DEVICE_I2C_ERROR (from NRF52I2C::waitForStop()), and that happens when the hardware raises an error event NRF_TWIM_EVENT_ERROR.

From that analysis I'd say that the problem lies below MicroPython, either in the CODAL or in the hardware.

In the version of microbit V2 is unstable, it will sometimes prompt OS error 19.

Hmm, so that means sometimes the code runs and sometimes it raises an OSError(19)? That seems to point to a hardware issue -- do you have pull-up resistors on the I2C SDA and SCL lines? What pins are used for SDA/SCL?

[dpgeorge]

Similar to #55, it may be possible to work around this issue by adding a small 50us delay after all I2C transactions.

[Leobriand31]

We are extremely interested at @vittascience to know when this issue is solved, many users are getting this bug (here).
Just like @lionyhw, the same hardware and code are stable in microbit v1.
Many of the libraries we created in this Github don't work anymore with V2, launching an "OSError(19)".

[dpgeorge]

CODAL was updated to v0.2.25 in 76054c2 and that might fix this issue. Would be good to retest.

[Leobriand31]

Thanks @dpgeorge, could you please provide us a new micropython firmware based on this new version of CODAL?
Or tell us how to do if that's easy.
If you'd like to test by yourself, I can send you a few I2C sensors that currently don't work with V2 and work perfectly with V1 (with the same code).
@jaustin & @microbit-carlos we start to get more and more angry customers and users because of this issue, since we sell a lot of I2C sensors for micro:bit at Vittascience... Several of our customers ask to return their micro:bits V2 because they consider it "unusable" with this issue. Please help us find a solution.

[dpgeorge]

@Leobriand31 you should be able to download a hex with this fix from here: https://github.com/microbit-foundation/micropython-microbit-v2/releases/tag/v2.0.0-beta.5

[Leobriand31]

It works perfectly, thank you very much!

[microbit-carlos]

Thanks everyone! Assuming all the I2C issues have been fixed I'll close this issue.
If anybody still has any I2C problems please feel free to reopen, or open a new one 👍