util/fpga_runner.py has test mode which dumps UART output to the terminal, useful for monitoring test logs
However it periodically drops large chunks of the UART stream
Steps to reproduce:
- First run the FPGA runner utility and capture the output in a text file
- Run
util/fpga_runner.py test -e <path to any test binary with a lot of deterministic UART output> 2>&1 > out1.txt
- Next run the test and use Picocom to monitor the UART:
- To start capturing, run
picocom /dev/ttyUSB0 -b 1000000 --logfile out2.txt (or equivalent)
- In a separate terminal, run
util/fpga_runner.py run -e <path to same executable>
- Return to the Picocom terminal and enter Ctrl+A-X to exit Picocom
- Diff
out1.txt and out2.txt
Workaround: use Picocom instead of relying on the UART monitoring in the Python script
Some of the diff will be due to standard output from the Python script which isn't captured by Picocom's UART monitor - this is not a problem:

However further down there are inconsistencies:

The behaviour is bursty - large chunks of the UART stream get lost - and seems to consistently happen around the same point during the log.
The stream does eventually recover:

For now using Picocom is a perfectly good workaround but this is really a bug with the Python utility
util/fpga_runner.pyhastestmode which dumps UART output to the terminal, useful for monitoring test logsHowever it periodically drops large chunks of the UART stream
Steps to reproduce:
util/fpga_runner.py test -e <path to any test binary with a lot of deterministic UART output> 2>&1 > out1.txtpicocom /dev/ttyUSB0 -b 1000000 --logfile out2.txt(or equivalent)util/fpga_runner.py run -e <path to same executable>out1.txtandout2.txtWorkaround: use Picocom instead of relying on the UART monitoring in the Python script
Some of the diff will be due to standard output from the Python script which isn't captured by Picocom's UART monitor - this is not a problem:

However further down there are inconsistencies:

The behaviour is bursty - large chunks of the UART stream get lost - and seems to consistently happen around the same point during the log.
The stream does eventually recover:

For now using Picocom is a perfectly good workaround but this is really a bug with the Python utility