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

[pavan]

Hi Hung,

First issue:

What are these connected to on your custom board?

• The Custom board which is being used to verify NCP, PINs P0.06 and P0.08 are open.
• PINs P0.04 and P0.26 are going to 3.3 to 1.8 Voltage level converter.
• The 1.8V UART signal via a connector is going to R-PI Module.
• We have used UART loop-back code with PINs P0.04 as nRF UART TX and P0.26 as nRF UART RX to verify connectivity, communication and orientation of the signals.
• If used some other code for R-PI and Custom board, that also working fine.

And are you sure you are not using P0.26 and P0.04?

• We updated NCP to support UART over P0.04 and P0.26 and the updated firmware worked with nRF52840-DK when we tested.
• But same firmware was not working with our custom board. We suspected it might be due to voltage level converter we are using for 3.3 to 1.8 conversion.
• So we took out 2 cables from PINs P0.06 and P0.08 from our custom board. These pins are not being used or connected to any interface, so we are sure there is no noise or error.

Whether there is a possibility 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.

• We also suspected same so I tried to use PULLUP in UART PIN P0.26 config for RX when using PIN4 and PIN26 as UART, but no change. So we tried using default Hex file for NCP without any change and traced UART via the cables we took out from PINs P0.06 and P0.08.
• We have also tried using J-LINK debug for both UART( P0.06 and P0.08 as well as P0.04 and P0.26), and if there was APP_ERROR_HANDLER(p_event->data.error_communication); or APP_ERROR_HANDLER(p_event->data.error_code); due to noise or something, application is supposed to terminate or halt, but application didn't halt or went to forever sleep as it normally does.
• We also tried to put break-point at if (!otTaskletsArePending(m_app.p_ot_instance)) just to be sure, and to verify if application is reaching there, but it's working fine waiting for an interrupt and we have not seen any change in working.

Regarding Noise as well as UART PIN issue: --

• If we use any other code whether it's using P0.06 & P0.08 or P0.04 and P0.26 (while using voltage level converter at P0.04 & P0.26) as UART, all custom codes or default examples or default hex used, follow below UART settings:
  • BAUD : 115200
  • Data Bits : 8
  • Stop : 1
  • Parity : None
• Everything program with UART works other than NCP UART.
  • So if noise or UART PINS had any issue, it can be seen when using any other example.
• For simplicity, we used UART Loop-Back Example and example hex file, to verify TX pairing and working.

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