Having issues with back to back printfs across the UART.

RE: Having issues with back to back printfs across the UART.

Robert — Fri, 02 Mar 2018 15:14:02 GMT

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

RE: Having issues with back to back printfs across the UART.

Bjørn Kvaale — Thu, 01 Mar 2018 14:42:17 GMT

Great! Good to hear that you figured it out!

RE: Having issues with back to back printfs across the UART.

Robert — Tue, 13 Feb 2018 22:00:38 GMT

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.

RE: Having issues with back to back printfs across the UART.

Robert — Tue, 13 Feb 2018 21:56:06 GMT

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

RE: Having issues with back to back printfs across the UART.

Bjørn Kvaale — Fri, 02 Feb 2018 11:54:56 GMT

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).

RE: Having issues with back to back printfs across the UART.

Robert — Mon, 29 Jan 2018 15:03:13 GMT

At one point I place a 500ms delay between each consecutive print in this code to see if I was overrunning the UART. I didn't see any improvement in the behavior and removed it. I know this is a crude replacement for HW flow control, but I was just checking if it could be the issue.

RE: Having issues with back to back printfs across the UART.

Matt — Fri, 26 Jan 2018 18:06:14 GMT

I have a similar set up to configure my custom board(nRF52832) also, although mine is less elaborate and the user on the PC end simply sends the AT commands and waits for ACK/NAK from the custsom board. Now the uart between pc and the dongle is fast while the BLE between the dongle and the custom board is "slow" (well, relative to the uart) so do you have h/w flow control enabled for the uart?

RE: Having issues with back to back printfs across the UART.

Robert — Fri, 26 Jan 2018 13:46:53 GMT

PC <--> UART <--> pca10056 <--> BLE(NUS) <--> custom board(nrf52840). The printfs are only running on the pca10056 and simply present the options allowed. Essentially using the pca10056 as a dongle.

RE: Having issues with back to back printfs across the UART.

Matt — Thu, 25 Jan 2018 14:27:52 GMT

Don't quite understand your setup here. Is it a simple "PC <-- uart --> nRF52" connection or a more elaborate "PC <-- uart--> BLE dongle <-- BLE --> nRF52-to-be-configured" ?