Potential problem for long term test with UART enabled

[scytulip]

I'm testing a data collecting program which samples data every 2s and reports it through UART (printf("data=%d\r\n", data)) on a PCA10001 board. I found this program may run into the error handler (FAILED) in some cases after running about 2 hours.

UART setting: 38400 Baudrate, hardware flow control

The pass/fail conditions are

1. PASSED: UART is enabled, USB is plugged into a computer, Terminal Emulator is running and receiving data from the COM port

2. PASSED: UART is disabled, USB is plugged into a battery pack

3. FAILED: UART is enabled, USB is plugged into a computer, no Terminal Emulator is running

4. FAILED: UART is enabled, USB is plugged into a battery pack

Particularly in the last case, even if I reset the chip, the program will run into the error handler directly after startup. The only solution is to plug it into a computer and reset again.

I guess there's a Tx/Rx queue in the Segger programmer chip. And when it's overflow, the Segger chip will block any further UART operation from nrf51822. Running a Terminal Emulator or reconnecting the USB cable can clear this queue.

I don't know whether this guess is correct. I write here to remind you, who are working on the evaluation kit, using UART for debug assertion and running long term program, to consider this potential issue.

[Nguyen Hoan Hoang]

Have you tried a high UART speed say 115200 or higher ?

[scytulip]

Seems OK. Do you know why?

[Nguyen Hoan Hoang]

Because it could take more than 2s to send your data through UART at that baud rate.

[scytulip]

But isn't it 38400bps (4.8KB/s)? Why will it take more than 2s to send data? May you provide me some materials explaining the detailed UART operations? Thanks.