Bit/Character limit on Central and Peripheral example

[Aashay]

I am using 2 nrf52832 boards to talk to each other through UART. One is programmed to the central SDK example and other other is peripheral. In the code, i incorporated 2 different types of app_timers. One that is a continuous loop that sends data out every desired interval. and the other type is that it waits for an input and sends it only after desired interval has passed after the most recent character. Well, i am using tera term to test the connection between the two boards. on the first config, when i use the "send file" option where i have prerecorded characters on a .txt file. there appears to be a limit on how many characters pass. it will pass upto 18 characters but restarts the UART if it is any more. on the second config, the send file only allows about 4 characters before restarting. what can i do or change to increase the amount of bits i can send simultaneously. 

[Simonr]

Hi

Are you using a JLINK device (DK or similar) to communicate with the computer? In that case, the baud rate of 921 600 is not supported due to the Baudrate calculations not matching that value. In our nRF52 DK user guide, this is stated as well. Are you not able to get any of the baud rates above 19200 to work either?

Best regards,

Simon

[Aashay]

so both boards are connected simply as serial ports. and i am talking to each other through tera term. and yes. i have tried all baudrates from 9600-921600 and nothing above 19200 works consistently without giving an error. so actually, i have commented out the error handler under APP_UART_COMMUNICATION_ERROR so that it can try to send as much. but if this were to be on, all the baudrates above 19200 would simply error out every time i try to send more than 7 or so characters in a .txt

[Simonr]

Hi

Could you check what the APP_UART_COMMUNICATION_ERROR returns? I suspect this is an OVERRUN error, which means that a start bit is received while the previous data still lies in RXD. What's recommended for higher baud rates is to implement the HW flow control as Håvard suggested early on. Is there a reason you can't do that? You could also try implementing the workaround he links to as well.

Best regards,

Simon