• State Verified Answer
  • Replies 11 replies
  • Subscribers 74 subscribers
  • Views 3004 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 233539
Options
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

Adam Gordon

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

    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. 

  • 0 in reply to Susheel Nuguru

    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?

  • 0 in reply to Adam Gordon
    Adam Gordon said:
    How would I go about enabling flow control to debug the issue? Also I would need the peer to use it as well, correct?

     Correct, you need peer to use it as well.

     

    Adam Gordon said:
    I agree that it might be something with the configuration of my device that changed during migration?

    moving from SDK14.2 to  SDK15.3 would mean that you are moving from nrf_drv_xxx to nrfx_drv implementation. I would assume it would be hard to get an exact configuration and code flow with these two. I wanted to see that if we do an experiment and enable flow control on both sides of the communication error goes away, then we can focus on eliminating this error instead of going around it.

    Also, If this is reproducible on the DK, then I could also try to replicate this on my desk and see if I can think of any solutions to fix it.

Reply
  • 0 in reply to Adam Gordon
    Adam Gordon said:
    How would I go about enabling flow control to debug the issue? Also I would need the peer to use it as well, correct?

     Correct, you need peer to use it as well.

     

    Adam Gordon said:
    I agree that it might be something with the configuration of my device that changed during migration?

    moving from SDK14.2 to  SDK15.3 would mean that you are moving from nrf_drv_xxx to nrfx_drv implementation. I would assume it would be hard to get an exact configuration and code flow with these two. I wanted to see that if we do an experiment and enable flow control on both sides of the communication error goes away, then we can focus on eliminating this error instead of going around it.

    Also, If this is reproducible on the DK, then I could also try to replicate this on my desk and see if I can think of any solutions to fix it.

Children
  • 0 in reply to Susheel Nuguru

    I enabled flow control and there were still issues with communication. Almost the exact same behaviour was observed:

    1. My device was able to receive the first UART message and transmit a response back

    2. The peer could not send a second message

    When flow control was disabled, and the peer sent the second message, my device threw the APP_UART_COMMUNICATION_ERROR. This time, with flow control enabled, I don't think the peer was able to send a second message at all. Therefore I did not observe the error this time, but my device did not receive any error either. I think the RTS line was deactivated, not allowing the peer to send the message.

    Unfortunately I am working with custom hardware, so I am not able to run my firmware on the DK.

  • 0 in reply to Adam Gordon

    Hmm, there are 6 buffers in the RXD FIFO, so problems with the second message itself sounds very suspicious. Communication errors even with flow control could mean some issues with your hardware.

    1. Double check the pins pulls on both sides.Maybe the pull/drive strength combination is wrong.
    2. connect your pins to the logic analyzer and check if the data on the pins are looking correct. I mean the start/stop bits, baudrate etc are as configured. The logic analyzer would also detect errors if you set the protocol to UART on the pins.
  • 0 in reply to Susheel Nuguru
    Susheel Nuguru said:
    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?

  • 0 in reply to Susheel Nuguru

    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.

  • 0 in reply to Susheel Nuguru

    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

Related
Terms of service