4

I have a strange issue I cannot figure out. I have a thermal printer (https://www.adafruit.com/products/597) plugged to the UART (/dev/ttyAMAO).

I configured the RPi to remove the console on /dev/ttyAMA0 with the following:

echo "dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait" > /boot/cmdline.txt
systemctl disable serial-getty@ttyAMA0.service

My project is running fine, except for one little thing.

Immediately after powering the RPi, the printer sometimes prints 5 random characters, as if something was sent to the UART.

Here is what it looks like (each line is a new powering of the RPi) binary_garbage

Any idea from where it's coming from?

Additional info: - the RPi is a model B - it runs Raspbian Jessie Lite

  • Try to configure a card to hang at various stages of the boot and see at which one the characters are generated. – Chris Stratton Dec 2 '15 at 16:33
  • You most probably need to add a pull down resistor to the RX/TX cables. As these pins are floating during the bootloader (the first and second ones, before the kernel is loaded) These floating values are causing junk on the UART. If you can program the printer.. then use a CRC like. <command><data><lenght><crc> - the printer checks the CRC and if its correct. it will print. This avoids pull downs, but also more robust.. all modern printers use this kind of control to make sure the data is valid. – Piotr Kula Dec 2 '15 at 19:45
8

The Pi's UART has a fault (in the firmware). Whenever the port is opened there is a 30 µs low glitch on TXD.

See http://elinux.org/RPi_Serial_Connection#Unwanted_serial_garbage_input and search for glitch.

You will need to find a workaround as the fault will not be fixed.

  • 1
    Thx joan, I already saw this, but as I say, the glitch happens right after powering the RPi, so the system is not started yet. So could it be what you mention? – xavier.seignard Dec 2 '15 at 15:06
  • I checked the Adafruit specs on the printer and unfortunately the printer doesn't have an RTS (request to send) input so you can't use that as a work-around. Perhaps you can wire a GPIO from the Pi as an input to a transistor to control powering on the printer and only power on the printer once the Pi has fully initialized. – HeatfanJohn Dec 2 '15 at 15:29
  • @xavier.seignard The port is opened early during boot. During Linux uncompression I believe, which happens before /boot/cmdline.txt is read. – joan Dec 2 '15 at 16:33
  • A 30uS glitch would not generate multiple characters. – Chris Stratton Dec 2 '15 at 16:37
  • @ChrisStratton Probably not, if the line just goes low I'd expect a single NULL (0x00) character. However boot messages at 115200 bps would cause problems for the printer. – joan Dec 2 '15 at 16:54
2

If these are wrong-baud-rate garblings of the the messages produced by the Kernel startup code, you could remove them by commenting out or disabling the lines in arch/arm/boot/compressed/misc.c which produce those, typically something like:

putstr("Uncompressing Linux...");

and

putstr(" done, booting the kernel.\n");

plus some atypical error cases, which you might want to leave intact.

The actual justification for this answer though, is that if you don't feel like setting up a build environment for the kernel, you could also leverage the fact that these are null-terminated strings, by using a hex editor on the raw kernel file to overwrite the initial characters of each argument ("U" and " ") with null (ie, 0x00). Make sure if you do this that you overwrite rather than insert, as the latter would render the remainder of the kernel meaningless.

An electrical gating of the transmit data line with a GPIO should also be fairly simple.

  • Very, very interesting. I had thought these messages were only displayed when earlyprintk was enabled! – Skynet Dec 3 '15 at 10:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.