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.

Parents
  • Can you do an experiment to enable the flow control (connect the flow control pins) and see if the communication error problem goes away? If it does, we would have one direction to debug this problem.

    I am suspecting that the peer and your device are not configured in a symmetric way for TX/RX. 

  • Hi Susheel, thank you for getting back to me! I just want to make sure to clarify I had no issues with UART communication when I was using SDK 14.2. The peer and my device were communicating without issue and without flow control.

    It has only been since migrating to SDK 15.3 that I have encountered an issue with UART communication. I agree that it might be something with the configuration of my device that changed during migration?

    How would I go about enabling flow control to debug the issue? Also I would need the peer to use it as well, correct?

  • 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?

  • No worries. It turned out to be an issue with configuration. When migrating to SDK 15.3 and still using legacy layers, there were a few competing configuration files that I was not aware of / had to make sense of. I spent time porting things over and merging sdk_config.h files, but then in the integration directory of the SDK, I had a templated nrfx_config.h file that was causing issues with getting the configuration I wanted (I had to strip it bare). And finally, under integration>legacy there is the apply_old_config.h file which then undefines and redefines configurations.

    All this to say getting those three files in agreement was an issue and setting things the same across multiple files did not result in desired configurations. So I stripped nrfx_config.h and worked out the configurations between sdk_config.h and apply_old_config.h and got the UART communication working again.

Reply
  • No worries. It turned out to be an issue with configuration. When migrating to SDK 15.3 and still using legacy layers, there were a few competing configuration files that I was not aware of / had to make sense of. I spent time porting things over and merging sdk_config.h files, but then in the integration directory of the SDK, I had a templated nrfx_config.h file that was causing issues with getting the configuration I wanted (I had to strip it bare). And finally, under integration>legacy there is the apply_old_config.h file which then undefines and redefines configurations.

    All this to say getting those three files in agreement was an issue and setting things the same across multiple files did not result in desired configurations. So I stripped nrfx_config.h and worked out the configurations between sdk_config.h and apply_old_config.h and got the UART communication working again.

Children
No Data
Related