Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

APP_UART_COMMUNICATION_ERROR after migration from SDK 14.2 to SDK 15.3

I have been migrating a project from SDK 14.2 to SDK 15.3 and have encountered an issue with UART. I am using the legacy layer with the following configurations:

#define UART_ENABLED 1

#define UART_DEFAULT_CONFIG_HWFC 0

#define UART_EASY_DMA_SUPPORT 0

#define UART_LEGACY_SUPPORT 1

#define UART0_ENABLED 1

#define UART0_CONFIG_USE_EASY_DMA 0

I am sending and receiving JSON strings and am having no issues with transmitting messages, I am seeing the same behaviour as before the migration. Unfortunately I am running into an issue with receiving messages. What's odd is that I can always successfully receive one message without issue. It is when receiving a second message that I get an APP_UART_COMMUNICATION_ERROR. Every message that follows will also get the same error. After observing this behaviour, I can still transmit messages without issue.

The app_uart_event has a type of APP_UART_COMMUNICATION_ERROR while the data fields of error_communication, error_code, and value are all equal to 1. I read in another thread that that is an overflow error, however my RX buffer is 256 characters, and the message it is receiving is 8 characters long.

I tried flushing after receiving the error using app_uart_flush() but it had no effect. I also tried disabling prs to see if that was the cause but it made no difference.

Any help with the issue or insight would be greatly appreciated.

  • problems with the second message itself sounds very suspicious

    That's why it's been difficult to debug.

    The thing is, I know it's not an issue with the hardware since the hardware has zero issues while communication while using SDK 14.2. It has only been since migration that I have run into the issue, which is why I feel like it's a configuration issue.

    Do you think it is worth remigrating my sdk_config.h file from scratch? Is there any guides to follow on the proper way to go about it, or do you have any suggestions?

    Unfortunately I don't have access to a logic analyzer to check on the data being sent. But is there anything I can try to further isolate the issue?

  • I've verified that it is not a hardware issue because I just loaded the UART example from SDK 15 and was able to send and receive messages over UART of varying lengths with no issue. I even tried importing the configuration for the UART drivers from the example into my own project and that did not fix the issue.

    Could it have something to do with the fact that I'm using app_uart_fifo? Or that I'm using a uart_event_handler? I'm just trying to figure out what it is that would be causing that error.

    Edit: I just checked the UART example from the SDK again and I initialize the uart in the exact same way in my project (with the fifo and event handler). So I don't think it's an issue with that.

  • I have an update with more information that might be helpful. I tried communication with my device using a different peer and had slightly different results. The error that occurred was the same, however sometimes my device would successfully receive 2, 3, 4, even 5 messages successfully before the error occurred.

    It is worth noting that both peers that I am currently trying never had any issues when using SDK 14.2

  • Do you have any other recommendations for potential solutions for me to look into based on the additional information I provided above? The issue remains unresolved and is significantly impeding our project's migration to SDK 15. Thank you.

  • Sorry for the late response. The problem seems to be on the peer side. I do not understand why it worked on SDK13 and now in SDK15, considering the peer is the same.

    Can you show me the logic analyzer output of the communication for both SDK13 (Which worked) and SDK15 (which is not working) so that we could analyze the pins to see if something has changed there?

Related