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

[Hung Bui]

Hi, 

What do you run on the R-Pi ? 

Could you give some more debug information on the nRF52 ? Is there any error, assertion ? 

What make the debug mode different from the non-debug ? For example on the UART trace ? 

[pavan]

Hi Hung,

Please find the below comments on your above questions,

What do you run on the R-Pi ?

• We used Boarder-router image over R-Pi.
• While doing UART trace, we didn't use R-Pi.
• There was some output over UART after boot depending on reset reason when using nRF-Dk.
• There was no output over UART when using custom board.
• The boot message mentioned above is as I have mentioned in the first mail.

Could you give some more debug information on the nRF52?

• I tried using debug mode instead of release mode, but no output or info was showing over the debug terminal.
• If some settings needed to be changed to get debug output let us know.
• NRF_LOG_ENABLED is set to 1.

Is there any error, assertion?

• When I pause the execution in debug mode after any amount of time, program current statement is still within one of below lines:-

        while (!otSysPseudoResetWasRequested())

        {

            thread_process();

 

            // Enter sleep state if no more tasks are pending.

            if (!otTaskletsArePending(m_app.p_ot_instance))

            {

                __WFE();

            }

        }

• Above indicate that there is no error assertion.
• If some specific location needs to be added with break-point to confirm above please let us know.
• I tried to place break-point over while (!otSysPseudoResetWasRequested()) or thread_process().
• Device is working without any errors only stopping due to above break-point.
• After checking over UART TX, nRF-DK had the output message but no output over custom board.

What make the debug mode different from the non-debug ? For example on the UART trace ?

• There was no change in execution.
• Depending on where I add break-point the UART output after boot in nRF-DK may get delayed. But no change in output observed.

Thank you

pavan S K

[Hung Bui]

Hi Pavan,

Our experts in Thread are currently on vacation. We unfortunately can't have an answer for you until second week of January. I'm sorry for this. 

[pavan]

Hi All,

Waiting for the reply in above query. Addition to this, 

We are working withThread commissioning and for that we needed EUI64 ID.

 

While testing we found that the EUI64 ID we got from CLI example and a code we created which uses otLinkGetFactoryAssignedIeeeEui64() gives different output for EUI64 ID.

When we tried checking what might be the issue, we found that the SDK version used, for the CLI example and our code, were different.

 

Now doubt is, if with different SDK version we will get different EUI64 ID, then in future when we upgrade Firmware for the older devices, the new firmware may be using SDK version released later on by Nordic. Hence the stored EUI64 ID for those will change. If we are using EUI64 ID bar-Code or some similar form for provisioning devices, then it may cause issue.

 

Below are the output from 2 nRF52840-DK used for testing.

nRF-DK 1:

Our Code                       : BC5E0BFA19BB8936

CLI with Same SDK       : bc5e0bfa19bb8936

CLI with Different SDK : f4ce36bc5e0bfa19

nRF-DK 2:

Our Code                       : F422010C382915A6

CLI with Same SDK       : f422010c382915a6

CLI with Different SDK : f4ce36f422010c38

Thanks in advanace

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