# GPIO stops working after several hours **URL:** \ **Category:** mangOH Red\ **Created:** [March 25, 2018, 5:26pm UTC](https://mangoh.discourse.group/t/gpio-stops-working-after-several-hours/1273 "2018-03-25T17:26:24Z")\ **Posts on this page:** 4\ **Page:** 2
**Author:** ![nick](https://sea2.discourse-cdn.com/flex016/user_avatar/mangoh.discourse.group/nick/32/1380_2.png) [@nick](https://mangoh.discourse.group/u/nick)\ **Post date:** [April 16, 2018, 6:43pm UTC](https://mangoh.discourse.group/t/gpio-stops-working-after-several-hours/1273/21 "2018-04-16T18:43:44Z")
Hey @asyal, I’ve been trying to get this issue to surface on our MangOH Red with no luck so far. I’m going to keep it running and see what happens. I had a theory that linked this issue to my host computer but unfortunately that contradicts my findings this morning. Do you have any ideas in terms of anything that could trigger this problem? In terms of deviation from the MangOH Red reference design, our board has the following changes: - Removed the `wm8944` audio codec - Removed the `pca954x` i2c hub - Removed the `sx150x` GPIO expander - Removed the USB hub - Removed the SPI over USB bridge - Kernel modules modified to use i2c bus `i2c-0` for everything - Removed code that probes for the `wm8944` - SD card detection GPIO pin moved (with corresponding changes in Yocto) - (Unrelated to hardware change) Enabled charging in an attempt to use the `ltc2942` I’ve also put together a small repository to show some of these changes: > **[nvandoorn/mangoh-red-kernel-changes](https://github.com/nvandoorn/mangoh-red-kernel-changes)** > > Contribute to nvandoorn/mangoh-red-kernel-changes development by creating an account on GitHub. ---
**Author:** ![nick](https://sea2.discourse-cdn.com/flex016/user_avatar/mangoh.discourse.group/nick/32/1380_2.png) [@nick](https://mangoh.discourse.group/u/nick)\ **Post date:** [April 16, 2018, 10:41pm UTC](https://mangoh.discourse.group/t/gpio-stops-working-after-several-hours/1273/22 "2018-04-16T22:41:44Z")
Performed another test here to try and eliminate the host PC as a factor. Booted the device with just battery power and connected my PC over micro USB exactly 30 seconds after boot. All of the `Bus still busy` errors occur within the boot time range of 1 to 17 seconds (see here [https://gist.github.com/nvandoorn/e1a9495a94ea06101de484c7598a2412](https://gist.github.com/nvandoorn/e1a9495a94ea06101de484c7598a2412)). Based on this, I don’t believe the host PC is a factor here (which unfortunately contradicts my initial hypothesis). ---
**Author:** ![nick](https://sea2.discourse-cdn.com/flex016/user_avatar/mangoh.discourse.group/nick/32/1380_2.png) [@nick](https://mangoh.discourse.group/u/nick)\ **Post date:** [April 23, 2018, 9:02pm UTC](https://mangoh.discourse.group/t/gpio-stops-working-after-several-hours/1273/23 "2018-04-23T21:02:52Z")
Hey all, Wanted to take a moment and report where we are at with this issue. After weeks of debugging, it seems this issue is a result of something in our hardware. Apologies for the confusion, Cheers! ---
**Author:** ![coastalbrandon](https://sea2.discourse-cdn.com/flex016/user_avatar/mangoh.discourse.group/coastalbrandon/32/264_2.png) [@coastalbrandon](https://mangoh.discourse.group/u/coastalbrandon)\ **Post date:** [May 1, 2018, 4:38pm UTC](https://mangoh.discourse.group/t/gpio-stops-working-after-several-hours/1273/24 "2018-05-01T16:38:34Z")
For everyone’s reference here’s what we discovered: - We had not included the I2C hub in our electrical design. We have now included the hub and have ALL devices connected to the I2C hub and a single data line going back to the WP8548. This resolved our ‘bus busy’ problem at boot. - We have found one unit so far (out of five) that has had a ‘bus busy’ after several hours, which may be indicative of the problem originally referenced in this thread. This is a unit that has the I2C hub in place. [Previous page](https://mangoh.discourse.group/t/gpio-stops-working-after-several-hours/1273.md?page=1)