jLink USB-UART chip on nRF9160dk malfunction

[Georgi Valkov]

We are currently experiencing malfunction with the big chip on nRF9160dk board, which provides USB-UART and jLink functionality.
After 30 minutes, to a few hours, we either stop receiving data from one or both of the USB-UARTs, or the data is garbled due to lost bytes.

Currently nRF9160 is using a modified version of the GPS sample, which sends a copy of the NMEA strings over UART1, to UART0.RX on nRF52840, while UART0.TX connects to the USB-UART on the computer. All samples and boards are attached to the case, except for the app running on nRF52840, which is provided as a binary image. The app is very simple: read from RX and write to TX. The source code we are using is shown on the video, but relays on a proprietary UART driver, which we cannot provide. The driver is very well tested and uses DMA to insure optimal performance and no drops of packets.

Following all tests from the videos linked below, we were able to exclude both CPUs: 9160 and 52840, as well as the software running on them. This leaves the chip providing USB-UART functionality as the only possible point of failure, confirmed after restarting power to the board.

https://youtu.be/04RJwDOnUE8
https://youtu.be/pwJoxr1ODTk
https://youtu.be/Dc6Hxk1oKuQ

8780.2021-03-17.7z

6303.nRF52840 UART-loopback.hex

3806.nRF52840 UART-loopback.7z

[Georgi Valkov]

nRF9160dk j-link/UART chip drops UART data

status: reproduced multiple times on two different nRF9160dk boards: the old one has a GPS antenna connected using a cable, the new board has the GPS antenna mounted on the board.

occurs: a few minutes after we connect the USB cable, the UART starts dropping random bytes or stops delivering data completely. This could affect either the UART connected to nRF9160 or nRF52840, or sometimes both at the same time:

https://youtu.be/6wDAXyt7Bvg

[Simon]

I've been on easter vacation the last week, hence the delay.

I took a brief look at the videos and saw that everything worked when you reset the nrf9160. I think this is because the UART communication between the 9160 and the 52840 needs to be in sync, as mentioned in this ticket. However, after that reply was given, a solution is implemented to fix this, check it out here: zephyr/boards/arm/nrf9160dk_nrf9160/nrf52840_reset.c.

If I have understood this correctly, the function in nrf52840_reset.c will run when the nrf9160 is reset, which will reset the 52840 as well and make it so that the UART communication are in sync.

Does this make sense? Have I understood your problem correctly?

Best regards,

Simon

[Georgi Valkov]

Hello Simon! Any update from your colleagues?

[Simon]

I've pinged the ticket internally. I'll go on vacation for a week, so I'll ask someone else to keep an eye on this.

[Georgi Valkov]

Hi Simon!

I just installed an updated probe firmware from 2021-07-02 10:44 on my nRF9160 board and spent the last couple of days porting my projects to the 1.6.1 SDK. Everything worked flawlessly during this. Has the issue been resolved?

An important thing to consider: many projects do not work across SDK versions, so users have to spend many hours to port them. Building usually fails due to removed or renamed CONFIG_ flags or API. I hope Nordic improves its development, to require less re-engineering when switching between SDK versions!

[Simon]

Hello, sorry for the delay. I've been gone the last 2 months. I'm happy you got it working. However, I'm not sure specifically what resolved the issue. I'll look into it.

Could you open another ticket about the porting question?

Best regards,

Simon

[Simon]

I see that I got some feedback in the internal ticket. I got informed that the nRF Command Line Tool v10.14.1 would resolve package loss of this type and that you should test it out when it gets released (The command line tools contains a version of the SEGGER J-Link software).

However, it seems like the issue got resolved for you. I'm glad that's the case, but I'm not sure why.

Best regards,

Simon

[Georgi Valkov]

Hi Simon!

I think the issue got resolved for me because I followed your good advice to update the board controller firmware using J-Link Configurator. I currently have JLink_Windows_V754a_x86_64 installed, and I assume the fix is present there. I don't think I have the Command Line Tool installed, unless it comes as part of nRF Connect, the Toolchain Manager or SDK v1.6.1. There is a note in the change log for nRF Command Line Tool v10.14.0 confirming the issue has been resolved:

- Improved modem serial DFU resilience to UART data loss by introducing re-sending of unacknowledged packages.

I'm curious if the board controller firmware gets updated automatically when using the Programmer or Segger Embedded Studio IDE which comes with the SDK?

Thank you for help! We can mark this case as resolved.