Lesson 1: gibberish output from hello world

[lnguyen4e]

I follow the tutorial in lesson 1.1. I successfully receive something from the terminal but it is gibberish. I put default rpi os into the sd card then follow every step in the lesson 1.1. My rpi run well with default os and with the baud rate 115200.

[TheShed412]

I was having a similar issue with the pi 3. It turned out I wasn’t giving screen the baud rate, is it possible that you aren’t using the right baud rate?

[anguslmm]

I'm having the same issue, and it doesn't seem to be the baud rate for me. The pi echos back characters perfectly fine. My gibberish is �TY5i��. Steps I've taken:

• Tried on both linux and windows, using screen and PuTTY respectively. Same gibberish output.
• Logging the output and doing a hexdump to see if the bits were offset, or there was a single bit flipped, etc. No discernible similarity to the intended message, seems to just be the same string of random bits each time.
• Commenting out the Hello World message. The gibberish doesn't show up. Similarly, if I change the message I get different gibberish, and if I send another message with uart_send_string, I get more gibberish.
• Tried using this cable with a fresh raspbian install. Works perfectly, no problems. Able to log in and use bash as normal.
• Changed the baud (on both sides) to 9600. Same result.
• Played with the baud on the desktop side, tweaking it up and down. Doesn't improve output, tweaking in either direction. Eventually the difference in baud rate is just too great and gibberish becomes much more random before stopping altogether.

At this point I was questioning basic assumptions and started doing weird stuff.

• Adding a delay call before the Hello World message, and during the string loop itself. No change.
• Powering off the serial cable, vs externally. No change.
• Adding individual uart_send(uart_recv()); lines before the uart_send_string("Hello, world!"); line. For however many uart_send(uart_recv()); lines I insert before the initial message, you'd expect it would wait for me to send that many characters before sending the message. But it waits for precisely half as many, and it also still sends one gibberish character at the beginning.

I ultimately changed the while loop in kernal_main to this:

	while (1) {
		//uart_send(uart_recv());
		uart_recv();
		uart_recv();
		uart_recv();
		uart_recv();
		uart_send('x');
	}

You'd expect that, for every four characters I send, I will receive one 'x' in return. But no. Instead, every two characters I send, I receive 0xCE in return.

It was at this point that I realized I need an adult.

I'm hoping there's an underlying cause that makes all these steps pointless, but I figured I'd include them in case they help. I really only kept going because of how consistent all this weird behavior was, which made me thing if I just kept pulling at threads I'd figure out what was wrong.

[anguslmm]

After sleeping on it, I realized this sounds a bit suspiciously like a 32bit vs 64bit problem. Will investigate this soon, but if anyone has tips, they’re very appreciated.

[anguslmm]

Started messing with the config.txt file and quickly found the issue.

The prerequisites link to the USB to TTL cable set up and test guide, which stresses the importance of having enable_uart=1 in your config.txt file. When things didn't work the very first time, I added that line and forgot about it, thinking it couldn't hurt to explicitly enable that. Turns out it can.

@lnguyen4e Do you have that in your config as well? If so, try removing it, and if it works, I may make a PR to make Lesson 1 explicitly say to exclude that.

[anguslmm]

Doing a little homework into why this happens, and it looks like weird stuff happens with enable_uart=1: https://www.raspberrypi.org/documentation/configuration/uart.md

In uart_init, we're turning on mini uart. So we don't want config.txt to turn on primary uart, especially since, as stated in the above article, the core clock gets locked to a specific frequency with that setting on. So enabling primary uart in the config.txt is obviously bad.