Published: 09.05.2021 | Edited: 09.05.2021 | Tags: 100daystooffload,arch,platformio,avrdude,arduino

Fix platformio avrdude input/output error

I have get to work on the very low priority side project with the codename bee weighter yesterday. It is not meant to weight the actual bees, but instead their entire house to determine if it is a full of honey that could be extracted.

However, I got greatly slowed down by the unfortunate issue that manifests itself as a following error in its entirety:

avrdude: ser_open(): can't open device “/dev/ttyACM0”: Input/output error

There is of course a Unix Stack Exchange thread discussing this, but the best thing I could extract off it was a sort of a workaround:

sudo modprobe -r cdc_acm && sudo modprobe cc_acm

I had to run this every time before any command that was doing something with the /dev/ttyACM0 port, be it uploading a sketch into the Arduino Pro Micro 3.3V/8MHz from SparkFun or accessing it's serial port, to either check the weight data or the datetime from the Real-Time Clock (RTC) chip. The only exception when the modprobe was not needed was if the serial port accessing commands were fired in a very short succession. It was very frustrating.

At first, I thought that maybe the linux-zen kernel I use to run F-Droid apps on Linux was a problem, and some searches were suggesting that a custom kernel might be an issue, but booting a regular kernel shipped with Arch did not solve the issue. I dual-booted to Windows 10 and everything worked there, just to be sure.

Then I have stumbled upon this comment in the Reddit thread discussing this problem too, and it solved the issue for me.

Long story short, the thread discussed that the problem is probably kernel related, pointing out kernel versions that exhibit this particular issue, but the solution for me as well was disabling an USB autosuspend feature. It is possible to disable an USB autosuspend from at least three places:

  1. via the bootloader kernel parameter (see Stack Exchange link above)
  2. via the udev rules (see links at the bottom)
  3. via tlp configuration (the solution from Reddit thread above)

I had tlp already installed. It is used for power management in linux. The solution is to edit /etc/tlp.conf, uncomment and edit USB_AUTOSUSPEND=0. After reboot, no the problem was gone.

Note that this probably means that the laptop might last a little less on batter power and a specific udev rule for this might be more optimal, I could not get it to work this way, but would love to see such solution.

This is a 60th post of #100daystooffload.

Links for udev