Errors and crashes when touching the GPIO pins

[panik]

I received my Raspberry Pi today (Yay!). I was planning on soldering up something to play with the GPIO pins. I had an IDC cable prepared with two female connectors. When I plugged one end of it on the pins 'to see how it looks', I was treated with multiple lines of the same error in the terminal. Copy/paste from dmesg:

Code: Select all

[  369.412007] SysRq : HELP : loglevel(0-9) reBoot Crash terminate-all-tasks(E) memory-full-oom-kill(F) debug(G) kill-all-tasks(I) thaw-filesystems(J) saK show-memory-usage(M) nice-all-RT-tasks(N) powerOff show-registers(P) show-all-timers(Q) unRaw Sync show-task-states(T) Unmount show-blocked-tasks(W) dump-ftrace-buffer(Z)

Thinking my cable was faulty (a short maybe), I cut it in half to see which of the two connectors was the culprit. Turns out it didn't matter; both halves generated errors (so, probably no shorts). No worries btw, I have spare cable and connectors.

Then I found out, that merely touching some pins with my finger generated the same error. I suspect it's one of the serial pins. Either GPIO 14 (TXD) or GPIO 15 (RXD), "but I can't quite put my finger on it" if you'll pardon the pun. If I'm stressing it a bit and generate a reasonable amount of errors, I'm being logged out, making LXDE seem to crash. Logging back in, the CPU bar in the bottom-right is filled up. 'top' however, shows 10-15% CPU for Xorg at most. Only a reboot calms everything down.

I'm running the april release of Debian, updated with Hexxeh's updater. Any ideas?

[jojopi]

Your unterminated cable or finger is feeding electrical noise into the UART RxD, as you say. This is interpreted as random input characters and serial breaks. The UART is configured as serial console by default, so a break on it is equivalent to pressing Alt+SysRq on the framebuffer console. Some of the SysRq functions produce a lot of kernel output and/or kill processes.

Removing "console=ttyAMA0,115200" from /boot/cmdline.txt will stop the UART being a serial console. Or adding "kernel.sysrq=0" to /etc/sysctl.conf will disable SysRq completely. If the noise is prolonged you may get failed login attempts on the serial getty too — comment out the "ttyAMA0" line in /etc/inittab to disable that.

[jbeale]

Given that the R-Pi is shipping without a case, and there isn't any common "plug and play" solution for using the UART.... should the baseline configuration take serial input by default, instead of requiring that to be explicitly enabled? I wonder how many other strange problems we've heard of on this board, were actually triggered by accidental finger contacts with the UART RX line. Does that pin have a weak internal pullup, or pulldown, or none at all?

[panik]

Thank you both. Removing the bit from cmdline.txt fixed the issue completely.

It was a bit disturbing, so I agree that some rethinking could be done on sensible defaults. Then again, you learn the most when things go haywire. At least now I know how to enable and disable these functions. Thanks again!

[aprgl]

I was also having the same problems, but not by touching the pins, instead using them communicating with a 3.3v FPGA, the DE0 board. It looked like maybe timing errors were causing serial breaks. Disabling AMA0 as above allowed minicom and pyserial to work! so... thanks!

[mahjongg]

Given that the R-Pi is shipping without a case, and there isn't any common "plug and play" solution for using the UART.... should the baseline configuration take serial input by default, instead of requiring that to be explicitly enabled? I wonder how many other strange problems we've heard of on this board, were actually triggered by accidental finger contacts with the UART RX line. Does that pin have a weak internal pullup, or pulldown, or none at all?

Initial software forgot to turn on the (strong) pullup, so the UART input pin became "finger sensitive" as described above, later distributions corrected this error.

[martinmarty]

Your unterminated cable or finger is feeding electrical noise into the UART RxD, as you say. This is interpreted as random input characters and serial breaks. The UART is configured as serial console by default, so a break on it is equivalent to pressing Alt+SysRq on the framebuffer console. Some of the SysRq functions produce a lot of kernel output and/or kill processes.

Removing "console=ttyAMA0,115200" from /boot/cmdline.txt will stop the UART being a serial console. Or adding "kernel.sysrq=0" to /etc/sysctl.conf will disable SysRq completely. If the noise is prolonged you may get failed login attempts on the serial getty too — comment out the "ttyAMA0" line in /etc/inittab to disable that.

THANKS, JOJOPI!