This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF52840 Multiple Instance UARTE with HWFC enabled RX bytes occasionally incorrect

I have a custom board with 3 nRF52840 chipsets, 1 central module is connected to 2 side modules.

The central module communicates with each of the side modules using UARTE with HWFC enabled.

For the most part this is working nicely, however occasionally one of the side modules will receive junk data into its UARTE buffer, even though this was not what was sent.

For example:
Central Module Sent:
13, 00, 03, 02, 01, 20, 02, 02, 00, 0B, 04, 08, 00, 04, 03, 01, 32, 00, 02, 02, 08

Side Module Received:

D3, 17, 49, 20, 7F, BD, A1, B4, DC, A8, 7B, 5A, FB, CD, 2D, 5B, 9B, 9A, C9, 27, DD, C2, 9E, BE, ED, C1, 2A, 8F, 1B, 2D, 62, F2, D9, C7, 57, BF, 36, 06, 13, 2D, 47, D6, 58, 95, 5F, AD, 05, DC, 13, 00, 03, 02, 01, 20, 02, 02, 00, 0B, 04, 08, 00, 04, 03, 01, 32, 00, 02, 02, 08, 65, 61, 64, 65, 72, 0B, 03, 01, D4, 08, 00, 00, D6, 08, 00, 00, 04, 00, 00, 00, F8, 79, 00, 20, A4, 25, 04, 00, 28, 57, 04, 00, 50, 57, 04, 00, FF, FF, 00, 00, 00, 90, D0, 03, 00, 10, 01, 40, 11, 00, 04, 00, FD, 21, 04, 00, 10, 7A, 00, 20, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00

I can see that the message I sent is contained within the bytes received but it should be at the front not somewhere squashed in the middle.

Like I said this only happens occasionally so for the most part this is working, and it usually only happens on 1 of the side modules. The current solution for dealing with this (not really a solution more of a work around). Is to programmatically reset the module if this happens continually for 20 minutes..

I am sending a lot of data quite frequently.

I have 2 UART buffers statically sized at 300 bytes (utilizing the secondary buffer).. So with every UART transmission, 300 bytes of data is sent. the first 2 bytes of my messages dictate the size of the whole message to actually be used.

I am using 1000000 baud rate (I tried to slow down the baud rate and it didn't seem to fix the issue).

Any Help on this would be greatly appreciated Slight smile

Regards,

David Hutchinson

Parents
  • Hello David Hutchinson,

    UARTE with HWFC enabled.
    however occasionally one of the side modules will receive junk data into its UARTE buffer, even though this was not what was sent.

    It sounds very strange to me that you are suddenly receiving data unexpectedly. Is the bus between the devices shared with any other functionality? Since you also are using hardware flowcontrol it is highly unlikely that this is 'noise' or similar.

    Could the data be unexpectedly queued in the application? Could you check the output buffer of the central module when this happens, and verify that it does not also contain the 'junk' part of the message?

    Do you have access to a logical analyzer? It would be greatly helpful if you could scope the lines and see what is happening on the lines when this behavior happens.

    Looking forward to resolving this issue together!

    Best regards,
    Karl

  • Turns out that the RTS pin was hooked up incorrectly and was mixed up with a Trigger line we were using to indicate a Startup event from the middle module.

    There was some confusion when mapping from GPIO to Nordic Pin

    Thanks for you help

  • Hello again David,

    Thank you for your patience with this. The summer holidays have begun here in Norway, and DevZone is therefore operating with reduced staff for the time being. Sorry for any inconvenience this might cause. 

    David said:
    Turns out that the RTS pin was hooked up incorrectly and was mixed up with a Trigger line we were using to indicate a Startup event from the middle module.

     Aha, I see. I am glad to hear that you were able to identify and resolve the root of this issue!

    David said:
    There was some confusion when mapping from GPIO to Nordic Pin

    Is there still any confusion, or anything I can be of help in clearing up?
    Please do not hesitate to ask if you should still have any questions, or if you encounter any new ones in the future! :)

    David said:
    i have to delay the initialization of the UART. It seems that if one side initializes before the other side is "powered up" the UART wont work and i need to re-init the uart at a later time.. This is really annoying and problematic having to put in artificial delays.

    This too sounds strange. The order of which the different modules should not matter, especially so when using hardware flow control to verify that both parties are ready to send or receive before proceeding. Is this still an issue after having found the incorrectly connected RTS pin?
    If so, please open a separate ticket on this issue, so we may look into it.

    David said:
    Thanks for you help

    No problem ta all, I am happy to help!

    Best regards,
    Karl

Reply
  • Hello again David,

    Thank you for your patience with this. The summer holidays have begun here in Norway, and DevZone is therefore operating with reduced staff for the time being. Sorry for any inconvenience this might cause. 

    David said:
    Turns out that the RTS pin was hooked up incorrectly and was mixed up with a Trigger line we were using to indicate a Startup event from the middle module.

     Aha, I see. I am glad to hear that you were able to identify and resolve the root of this issue!

    David said:
    There was some confusion when mapping from GPIO to Nordic Pin

    Is there still any confusion, or anything I can be of help in clearing up?
    Please do not hesitate to ask if you should still have any questions, or if you encounter any new ones in the future! :)

    David said:
    i have to delay the initialization of the UART. It seems that if one side initializes before the other side is "powered up" the UART wont work and i need to re-init the uart at a later time.. This is really annoying and problematic having to put in artificial delays.

    This too sounds strange. The order of which the different modules should not matter, especially so when using hardware flow control to verify that both parties are ready to send or receive before proceeding. Is this still an issue after having found the incorrectly connected RTS pin?
    If so, please open a separate ticket on this issue, so we may look into it.

    David said:
    Thanks for you help

    No problem ta all, I am happy to help!

    Best regards,
    Karl

Children
No Data
Related