UART communication issue thread

[pavan]

Hi All,

We are trying to interface nRF52840 based custom board, manufactured using Config 6 schematic as the reference, with R-Pi to work as NCP. Please refer to the attached schematic .

 

We found that the RPi was not able to communicate with the custom board, so when we tried to trace UART signal between R-Pi and our custom board as well as nRF-DK (nRF52840-DK 1.0.0), we found following results:

 

S. No.	Test	Result with nRF-DK	Debug mode Result with nRF-DK	Result with Custom board	Debug mode Result with Custom board
1	R-Pi Thread NCP Connectivity.	NCP  Connected	Device Running.	NCP  Not-Connected	Device Running.
2	UART TX Trace On J-Tag Reset without R-Pi connection.	Hex data : 7E 80 06 00 72 FC 57 7E	Device Running.	No data	Device Running.
3	UART TX Trace On Switch Reset without R-Pi connection.	Hex data : 7E 80 06 00 71 67 65 7E	Device Running.	No data	Device Running.
4	UART TX Trace On Power-Reset without R-Pi connection.	Hex data : 7E 80 06 00 70 EE 74 7E	Device Running.	Hex data : 7E 80 06 00 70 EE 74 7E	Device Running.

 

Note: --

    1) NCP firmware PATH:  SDK_DIR\examples\thread\ncp\ftd\uart\pca10056\blank\ses

    2) To verify if UART TX and RX is working, we used: SDK_DIR\examples\peripheral\uart\pca10056\blank\ses, and were able to verify that UART communication was working fine.

    3) UART TX and RX is checked on PIN P0.06 and P0.08 respectively of nRF-DK and custom board.

please suggest 

Thank you

PNordic_nRF52840.pdfavan S K

[Edvin]

Hello Pavan,

First issue:

So what you are saying is that your custom board is not communicating via UART, in most cases, when running the NCP application?

I am a bit confused. You say that the UART is using pins 6 and 8, like in the default project. What are these connected to on your custom board?

And are you sure you are not using P0.26 and P0.04? Or do I misunderstand? What I really am asking is whether there is a posibility for noise on your UART's RX pin, or if it is held low when there is no UART data, which may cause an APP_ERROR in the uart drivers. 

Second issue:

What SDK versions were you testing on when you received the different addresses? 3.2.0 and 4.0.0?

[pavan]

Hi Hung,

Second issue:

IDE Info:--

SEGGER Embedded Studio for ARM
Release 4.30b  Build 2019111305.40571
Windows x64

 

J-Link:--

J-Link V654c

 

SDK Ver, hex file and output:--

D:\nRF5_SDK_for_Thread_and_Zigbee_2.0.0_29775ac\examples\thread\cli\uart\hex\nrf52840_xxaa.hex

> eui64

bc5e0bfa19bb8936

Done

 

D:\nRF5_SDK_for_Thread_and_Zigbee_v3.2.0_9fade31\examples\thread\cli\ftd\uart\hex\nrf52840_xxaa_pca10056.hex

> eui64

f4ce36bc5e0bfa19

Done

 

Both output are from same nRF52840-DK.

If any other info is needed please let me know.

Thanks in advance

pavan s k

[Edvin]

Hello,

I see, and I see the same as you. I can tell that both of the addresses are fetched from DEVICEID[0..1]. If you look at the openthread commit that was used in SDK2.0.0, and compare it to the commit for SDK3.2.0, you can see that it has changed a bit. OPENTHREAD_CONFIG_STACK_VENDOR_OUI is defined in openthread-core-nrf52840-config.h, and it is the same for all Nordic devices. This also means that it will not change in the future. 

If you want to revert this, it is possible to build the openthread library yourself, and change this function back to the old implementation, which only uses the Device ID. 

But as I mentioned, this will not change in the future. This OUI is registered with IEEE, and you can find the ID here:
http://standards-oui.ieee.org/oui.txt (search for Nordic Semiconductor ASA). This registration was probably done between SDK2.0.0 and 3.2.0 at some point (I have not checked what SDK that the change was applied).

As for the original question. Have you tried to debug the application running on the custom board? Perhaps you can try to ground CTS on the custom board, to check if there are any issues with the HW Flow Control.

Best regards,

Edvin