App_uart manifests as one byte buffer.

[EugeneBrod]

Hi,

I am running into this issue when receiving over uart where the byte received is always one byte behind relative to the byte sent by the sender. The byte received is either, a) nothing if it's the first communication, or b) the byte of the previous message sent by the sender.

I get this behavior in both the unchanged uart example, as well as the libuarte example in SDKs 15,16,17 (haven't tested others).

For example:

Sent: 0

Received: 

Sent: 1

Received: 0

Sent: 2

Received: 1

What do I have to change in the uart and libuarte loopback examples to see the following behavior?

Sent: 0

Received: 0

Sent: 1

Received: 1

Sent: 2

Received: 2

[Jørgen Holmefjord]

Hi,

This is not the normal behavior of the example. I tested out the UART peripheral example from SDK 17.1.0 just now, and I can send one character from the PC terminal (specifically "Termite", with settings set to "append nothing", to avoid any CR/LF bytes affecting the test), and I receive the character back from the nRF52 DK. 

What are you using to send the data to the nRF52 device? Have you verified that the data is actually sent out from the sender (using logic analyzer, etc)?

Best regards,
Jørgen

[EugeneBrod]

Also, both my coworker and I are connecting to the uart on the pca10040 board with a USB cable. 

[EugeneBrod]

Sorry for all the follow-ups but I think the detail could help.

I see the same behavior using the pca10056 chip with the USBD CDC ACM example. What could be causing this one byte delay on our machines?

[Jørgen Holmefjord]

EugeneBrod said:

What could be causing this one byte delay on our machines?

It's hard to say exactly what is causing this, but there may be some buffering somewhere that is causing this. Since you are seeing the same behavior with different examples and kits, it sounds like it is the other side of the UART that is the problem, but it would help to verify this if you could get hold of a logic analyzer of check the UART lines with a scope, to see if the data is transmitted/received when expected.

Do you have a Windows PC where you can test with Termite as described in my previous post, or putty with the recommended settings? Also make sure that you have the USB connected directly in the PC, and not through a hub, etc.

[EugeneBrod]

I've found a work around for now, I will come back to this eventually, but since this doesn't seem to be a NRF issue I think we can close this thread.