UART communication issue thread

RE: UART communication issue thread

Edvin — Fri, 31 Jan 2020 11:18:51 GMT

[quote user="PK"]What's the use of Hardware Flow Control in NCP?[/quote]

HWFC is used to ensure that the receiver is ready to/capable of receiving more UART packets. If the receiver is busy decoding the previous packet, then it will block the sender, and tell it to wait until it receives the "go" signal on the HWFC pins.

[quote user="PK"]Is it compulsory to have Hardware Flow Control in NCP?[/quote]

I don't think so.

[quote user="PK"]If we disable Hardware Flow Control in NCP, will it effect NCP working or UART communication in any way?[/quote]

It disables the feature that comes with HWFC. If the receiver is not ready to queue up more bytes on the UART, some UART data bytes may be lost if HWFC isn't enabled.

RE: UART communication issue thread

pavan — Fri, 31 Jan 2020 04:55:22 GMT

Hi ,

Problem was likely to be Hardware flow control.

We disabled the hardware flow control from NCP firmware and it is working now. Thank you.

will try to see if we can get it working with hardware flow control also. Please input if any suggestion regarding hardware flow control.

We have few queries:

What's the use of Hardware Flow Control in NCP?
Is it compulsory to have Hardware Flow Control in NCP?
If we disable Hardware Flow Control in NCP, will it effect NCP working or UART communication in any way?

Thanks in advance

Pavan s k

RE: UART communication issue thread

Edvin — Fri, 10 Jan 2020 08:38:34 GMT

[quote user="PK"]and i am not getting REPLY option to my latest post..[/quote]

DevZone has this issue sometimes. Just reload the site a couple of times, and it should appear after a while.

So you have a pullup on RX on the nRF, is that correct?

[quote user="PK"]PINs P0.04 and P0.26 are going to 3.3 to 1.8 Voltage level converter.[/quote]

Have you tried to analyse the 1.8V part of the UART? Are you sure there are no data there?

Are you using HW Flow Control on the UART? If you are not sure, please let me know.

From your original post. Are you saying that it always works on the custom board when you are running debug mode?

Have you monitored the logging on the NCP application running on your custom board? What does it look like compared to when you run it on the DK?

RE: UART communication issue thread

pavan — Fri, 10 Jan 2020 05:22:00 GMT

Hi Hung,

I have updated the details below , waiting for reply. and i am not getting REPLY option to my latest post..

thanks in advance

pavan s k

RE: UART communication issue thread

Edvin — Wed, 08 Jan 2020 14:25:46 GMT

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

RE: UART communication issue thread

pavan — Wed, 08 Jan 2020 13:41:47 GMT

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

RE: UART communication issue thread

pavan — Wed, 08 Jan 2020 10:18:32 GMT

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

RE: UART communication issue thread

Edvin — Wed, 08 Jan 2020 10:14:16 GMT

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?

RE: UART communication issue thread

pavan — Mon, 06 Jan 2020 06:15:40 GMT

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

RE: UART communication issue thread

Hung Bui — Fri, 20 Dec 2019 10:05:16 GMT

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.

RE: UART communication issue thread

pavan — Thu, 19 Dec 2019 07:25:45 GMT

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

RE: UART communication issue thread

Hung Bui — Wed, 18 Dec 2019 14:33:27 GMT

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 ?