OSError: [Errno 5] Input/output error on code.py save

[skerr92]

When I was developing the driver code for my touch sensor, I would occasionally receive the error: OSError: [Errno 5] Input/output error in the MU Editor serial monitor.

I could either wait for the filesystem to refresh or resave the code.py file. It isn't consistent and sometimes happened on hard resets via the reset button.

Using Qt Py CP6 build from 11/13/2020.

One other users in the discord help with CircuitPython channel also mentioned the same issue.

I'll be checking this with my CP Sapling M0 and the Feather M4 Express and update.

[skerr92]

I think it might be related to this i2c bus error from October. #3376

In my code I was using i2c. The user in the discord channel was using audiobusio I2S.

[ladyada]

are you using an editor that flushes the file completely to disk. try mu

[skerr92]

I should have mention that I was using the MU editor

[skerr92]

It might be a Qt Py specific issue, I'm trying it out on my CP Sapling (also an samd21e18a) though I'm not seeing it replicated.

[skerr92]

Wait, I got it to reproduce. Here's the output:

code.py output:
Traceback (most recent call last):
  File "code.py", line 7, in <module>
  File "/lib/odt_at42qt1070.py", line 119, in __init__
  File "/lib/odt_at42qt1070.py", line 145, in reset
  File "/lib/odt_at42qt1070.py", line 125, in _write_register_byte
  File "/lib/odt_at42qt1070.py", line 125, in _write_register_byte
  File "adafruit_bus_device/i2c_device.py", line 102, in write
OSError: [Errno 5] Input/output error

Press any key to enter the REPL. Use CTRL-D to reload.soft reboot

Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
0
2
0
2

Upon reload, it works fine.

[deshipu]

That looks like unreliable connection on the i2c bus. How long are the cables you are using? Are they soldered or just inserted into a breadboard? Do you have any additional pull-up resistors on the lines?

[skerr92]

It’s connected over Stemma QT, 10k pull ups on the breakout PCB soldered on. I’d be inclined to agree with you if I was getting “no device detected” but the trace back doesn’t return past the write operation to confirm one way or the other.

[skerr92]

@deshipu It might be isolated to the i2c device I'm using currently which only uses Adafruit_Bus_Device, I might try to use Adafruit_register as well to see if that helps any. It was mentioned to me that there was some issue with Adafruit_bus_device (hence the freeze in core builds).

[tannewt]

@skerr92 Please test with an Adafruit breakout. I think i2c pull ups are usually 4.7k or lower.

[skerr92]

@tannewt data sheet says 1-10k. I can build a second board up with 4.7k and verify.

[dhalbert]

Adafruit boards usually use 10k pullups on our breakouts. A few devices require stronger pullups. But it sounds like you are using an old build. Please try 6.1.0-beta.3 because of recent changes to restore using non-native adafruit_bus_device.

[dheera]

Possibly related to #3986
Try disabling the autoreload while editing. Also don't edit directly from the mounted microcontroller. Edit somewhere else and copy the modified file. That worked much better for me.
Sometimes editors [mess up] the filesystem with swapfiles and the like.

[skerr92]

When I get time this weekend I’m going to be testing out some changes to the init for the library.

The touch sensor has a restart time default of 125ms so I’m going to change the sleep time to 125ms and see if this goes away.

I’ll also try your solution @dheera

[dhalbert]

I was also seeing Errno 5 in the course of testing AnalogOut for #3966. It was a second error that occurred while trying to reference the AnalogOut, after it had been smashed by an incorrect memory write. So this may be an I2C object smash.

[jepler]

@dheera Using profanity in our github issues isn't appropriate. Please edit your comment, and check out our Code of Conduct if you need to know more.

[skerr92]

@dhalbert any way of knowing for certain of that’s what’s happening here? I’ll build a new uf2 off the current beta with debugging if need be. I still need to test with the bleeding edge to see if has the same issues.

[dhalbert]

@skerr92 Sure, test the latest, but the fix I had wouldn't fix this. I was just noting I got a similar error due to smashed *ioobjects.

[skerr92]

@dhalbert i think it may come down to busio objects not being properly guarded and getting smashed in the middle of execution. I’m not exactly sure how to approach fixing that issue, but BusIO seems to be the common flaw for the few people encountering this.

I’ll be testing changes today and report back.

[dhalbert]

I didn't see that this was SAMD21, sorry. I think it is unlikely to be a memory smash on that board. If you look at ports/atmel-samd/common-hal/busio/I2C.c, error 5 (MP_EIO) can be generated if the underlying HAL drivers return an error due to some problem in communicating with the chip. This could be due to a peculiarity of some kind of the particular I2C peripheral you are using. I don't see which one it is above (though I may have missed it).

[skerr92]

Yeah, this was one thing I was going to test for (see an above comment about the reset duration I mention). I imagine that it should solve the issue. Once i test that, I’ll update the issue or close as needed.

[skerr92]

Okay, I'm fairly confident now that it's just a timing issue on reseting the touch device so I'm going to go ahead and close this issue.