Having issues with back to back printfs across the UART.

[Robert]

I am using the "Nordic Uart Service", example to create a simple serial console which allows a user to change settings such as tx power, advertising intervals so that different combinations of these settings can be characterized. As such a simple text menu is printed out. The issue is that after I exceed a certain amount of characters the output no longer appears.

Is there a limit to the number of characters I can transmit in a given time, currently I am flushing stdout in order to force all the output to the terminal screen.

The device isn't hung up, at this time further print operations work, the only relation is that the prints are back to back for list of commands.

[Bjørn Kvaale]

When you write: "after I exceed a certain amount of characters the output no longer appears." after how many characters does the output no longer appear? These two links might be useful (link 1, link 2).

[Robert]

The following is the list of simple commands which I am trying to display.  Each is a printf in a loop, printing to the UART.  The uart is through the USB, initially I suspected that the HW hand shake may not be working and inserted a delay between each printf to allow the serial driver to catch up.  This did not seem to help.  Many of the lines are beyond the 20 chars per packet but it doesn't seem to have a problem until the total number of characters exceed 512 bytes.  The problem does not occur in subsequent prints, unless they also exceed 512 bytes.  This is just a simple test application.

disconnect() disconnect peer
connect() re-connect to peer
list() display list
reboot() reboot console
scan() scan peers
test() simple send and receive of the text "test"
tgt_reboot() reboot peer
uptime() current uptime in seconds/mseconds
ble_shutdown() shutdown ble softdevice
help_vars()
help() your looking at it
connect(arg) reconnect with the last connected peer
tgt_name(arg) "1234567" - include the quotes, maximum 7 chars
loopback(arg) itterati

[Robert]

UART_TX_BUF_SIZE is 512, increasing this does resolve the issue. I am guessing that the printf isn't a blocking call when buffer fills, joys of not having an OS.  Thank you for your patience and help.

[Bjørn Kvaale]

Great! Good to hear that you figured it out!

[Robert]

Just needed someone to ask me the right questions, thanks for the help.