OS error when attempting to write to pin

We are getting issues when trying to set a GPIO pin using gpio - v0.3.0 · PyPI, it keeps reporting

hardware    File "/env/lib/python3.7/site-packages/gpio.py", line 65, in wrapped
hardware      _write(f, pin)
hardware  OSError: [Errno 16] Device or resource busy

The only change that we are aware of which could affect this part of the code is updating to balenaOS 2.56.0+rev1. We have devices running quite happily on balenaOS 2.51.1+rev1. I am going to move an older device to this app to confirm that the error is not due to any changes in the code.

The device uuid is 19b190fd9231b1ee57201193b8e58f05 and I have enabled support access. No expectation to check the device, just thought it would shortcut a potential next step.

Hi there – thanks for getting in touch with us. I’ll check with our engineers about whether there have been any changes in the OS, but in the meantime let me ask a few questions:

  • It looks like this particular device is a Raspberry Pi 4. You mentioned that there are other devices that don’t exhibit this problem; can you confirm that they’re in the same application, running the same version of the code, and running the same hardware?
  • Are you able to take a Raspberry Pi4 running the older OS – one that does not exhibit this problem – and then upgrade it to 2.56.0+rev1 to see if it begins to exhibit this problem? This would eliminate the chance that there’s any difference in configuration between the two.
  • Can you let us know which GPIO pin you’re using?

Thanks in advance,
Hugh

Hi there, thanks for your response. I have just created a new device and it has downloaded the exact same version of code. The environment variables are almost exactly the same, aside from the DEVICE_ID.

During the hardware service startup it pulls pins [5, 6, 8, 9, 11, 16, 20, 23, 24, 25] high. I can see there are a number of clashes in the Pi GPIO table. In addition some of the pins we setup twice.

Both devices are in support mode, they are running with no hardware attached and can be updated or changed as desired. I will push an update to the code which will prevent pins being setup twice which could well be a contributing factor.

The devices have downloaded the update where a single pin is only configured a single time and dawn-thunder is still failing. For the moment we are going to avoid using the latest version of BalenaOS. Please let me know if anything changes.

Hi, can you set-up a simple reproduction app and share it please?

I have created an example repository hpgmiskin/balena-gpio-debug: Debug repository for issue with Balena GPIO access. When moving devices dawn-thunder and holy-fire to the application the device running the latest BalenaOS throws errors.

Through changing the GPIO_PINS environment variable it looks as though the issue is specific to GPIO7 and GPIO8. That being said I have not tested every single GPIO pin on the device. As an interim measure we will delay updating BalenaOS until a time when we can stop using the problematic pins.

Both the above devices have support access enabled until tomorrow. Please let me know when they are no longer useful and I can move the devices away from the current application and use them for other testing?

Hi, we were able to reproduce the issue with your example and created a tracking ticket for it: https://github.com/balena-os/balena-raspberrypi/issues/546 . There has been a kernel update between the two OS versions which might be the issue. We will update you as we have more information. You can use your devices as you wish now, I do not think we need them anymore. Thanks for your effort.

1 Like

Hi,

The Pi4 kernel was updated between 2.51.1 and 2.56, and the new version 5.4 no longer allows for gpios taken by spi to be exported: https://github.com/raspberrypi/linux/issues/3749
Gpios 7 and 8 are defined as chip selects for spi, which is enabled by default.

If you need these pins, the first solution would be to disable spi from the dashboard:
Device Configuration -> Define DT parameters -> Remove “spi=on”. Board will reboot and your test App should run fine.

Second option would be to reassign the CS pins to some other GPIOs you don’t use. In dashboard, edit “Device configuration -> Define DT overlays” as described here: https://github.com/raspberrypi/linux/issues/3749#issuecomment-663401962