This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
One GPIO (GPIO5B3) not working?
#1
Calling on GPIO experts....

This one has me perplexed. I can control most of the the other GPIO pins with Tinker's version of gpio from the shell. However, physical pin 18 (GPIO5B3) doesn't seem to work completely. I need to set it to an output and drive it to 1. I've tried with the latest TinkerOS (4.4.132+) and with Armbian Buster for the Tinker Board S.

When it first boots up, a "gpio readall" shows that pin 18 is SERL.

First, I change the mode to output:
Code:
gpio mode 5 out

I can verify this with another "gpio readall". It now shows that pin 18 is OUT

I then try to set the value to 1 with
Code:
gpio write 5 1
The pin never goes high and I verified this with a multimeter.

For grins, I tried the same test with pin 16 (GPIO5B2) and setting it to OUT with a value of 1 does work.

So I went native and did:
Code:
echo 163 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio163/direction
echo 1 > /sys/class/gpio/gpio163/vaue
cat /sys/class/gpio/gpio163/value

This didn't work either as a got a 0 back from the value even though I set it to 1. I checked the /boot/hw_intf.conf to see if I was fighting an overlay and I had the default that comes with the TinkerOS (uart1/4 on, uart2/3 off, i2c1/4 on, spi0 off, spi2 on,  etc). I don't have any applications running that might interfere (I don't think) and no hats are plugged in. This problem persists with two different OSs as well.

What am I missing? Hopefully something simple I've overlooked...
Reply
#2
It turned out to be a hardware issue. The board seems to have a part broken off between the CPU and header and there is also some solder splatter need the header as well.


I tried on a new board and all is well.


Attached Files Thumbnail(s)
   
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)