Does anyone else have problems with output?

(岩倉 澪) #1

This happens to me all the time, not sure if there is just a defect with my board or something wacky with my system…

When I connect to the hifive1 with gnu screen, I often need to hit the reset button multiple times to get the proper output to show up. Sometimes nothing prints at all, sometimes the start of it is cut-off by varying amounts.

I’ve attached a screenshot below from one of my episodes. In this example, I hit the reset button 3 times without getting any output, 4th try I got partial output, 5th full output, 6th partial output, 7th full output

This seems to be unrelated to calling fflush, happens regularly with proper programs. As far as I can tell the board itself is working fine for me though, I just have inconsistent output. It’s only a minor annoyance, but I’d love to figure out what is going on with it!

(Megan A. Wachs) #2

I believe this is caused by the fact that the UART line is dropped low during reset on the HiFive1, and the code is not waiting long enough to start sending on the UART after enabling it.

UART TX works with a single line, which starts high, then when the sender wants to send something, it pulls the line low to indicate a START bit. The receiver looks for the line going low as the START bit, then starts “reading” the bits that are sent by sampling periodically (according to the baud rate or trying to detect the baud rate).

If the TX line drops low/bounces around for some reason (such as during reset, or while the GPIOs are being configured as the UART pins), the receiver might think it’s a start bit, start interpreting junk as characters, and missing the real START bit and characters.

You could test this on your system this by putting a busy loop in the uart_init function after the GPIOs have been configured for UART, to give some time for the receiver to resynchronize and be ready to receive. You can see an example in led_fade demo, which doesn’t use the uart_init function in init.c:

(Bruce Hoult) #3

I get this on the preloaded blinky/SiFive logo program and NOTHING ELSE.

(岩倉 澪) #4

Didn’t do too much printing today, but so far this seems to be working for me, 10000 was too short but it seems to work with this large of loop:

volatile int i = 0;
while(i++ < 1000000);

(Megan A. Wachs) #5

That makes sense. The shorter loop was for a 16MHz clock frequency, if you are adding this to your code after you bumped the frequency, you’d likely need a longer delay.