nRF9151DK v0.9.0 USB UART stops working

[droberson]

Hello,

I have been developing on a nRF9151DK v0.9.0 for a few weeks now. So far this board is great! However, I have been running some long duration tests recently and logging through the default UART backend that is piped through the USB connector (J6) as a virtual COM port.

The issue I am seeing is that after some random amount of time (less than 24 hours), I no longer receive any UART messages. Yet, the COM port is still connected and open on the PC and the devkit application is still working as expected, indicated by LED activity.

I reproduced this with a simple example in the nRF Connect SDK:

My setup:

• Windows 11 PC
  • This PC never goes to sleep, only turns the screen off. I have another piece of hardware logging on a different COM port on the same machine for over a week now without interruption. It is a dedicated test PC, not my development PC. Thus, it is not being interacted with during my tests.
• nRF9151DK connected to PC via USB-C cable from J6, which is also powering the DK.
• Modem firmware: mfw_nrf91x1_2.0.1
• nRF Connect SDK / Toolchain: 2.9.0
• Terminal app: PuTTY
• nRF Connect Sample App: zephyr/samples/basic/blinky
• Build configuration
  • Board: nRF9151dk/nrf9151/ns
  • Leave the rest of the build configuration settings at their default values

Simply build the application, flash it onto the DK, and open the application COM port. You will see LED1 blink continuously along with the following repeated output:

*** Booting nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***
LED state: OFF
LED state: ON
LED state: OFF
LED state: ON
LED state: OFF
LED state: ON
LED state: OFF
LED state: ON
LED state: OFF
LED state: ON
LED state: OFF

Let this run overnight and check it the next day. No more messages are received on the COM port yet the LED is still blinking.

Is this a known issue on this devkit? Seems like there are many points of potential failure. I imagine this UART is piped through the nRF5340 on the DK, maybe it's getting hung up there.

Any input would be appreciated. We plan to use a UART to talk to a co-processor in our final design so I want to mitigate any risks or issues. Hopefully this is an issue with the devkit or something other than the nRF9151 SOC.

Thanks,

Derek

[Sigurd Hellesvik]

Hi,

I assume you try to reconnect Putty right?

Does resetting work?

If you increase the frequency of the logging, will the error happen sooner?

Regards,
Sigurd Hellesvik

[droberson]

Hey Sigurd Hellesvik 

I let the devkit run overnight, and I see that it stopped logging again, but the COM port is still open as previously observed. The last series of log messages are:

[00:11:27.816,375] <inf> led: LED state: ON
[00:11:27.916,473] <inf> led: LED state: OFF
[00:11:28.016,571] <inf> led: LED state: ON
[00:11:28.116,668] <inf> led: LED state: OFF

Thus, it ran for 11 hours and 28 minutes with SLEEP_TIME_MS set to 100.

Sigurd Hellesvik said:

Does resetting work?

Pushing the reset button (SW5) does not resolve the issue. I see the nRF9151 SOC reset indicated by a momentary pause in the blinking of LED1. The COM port remains open but nothing comes through.

Closing and reopening the COM port resolves the issue as previously observed.

Sigurd Hellesvik said:

If you increase the frequency of the logging, will the error happen sooner?

Since my last test was the first one where I was logging timestamps, I have reverted SLEEP_TIME_MS from 100 to 1000 and will run another overnight test to see if it takes longer to occur. I will report my findings once I have them.

Edit: It could be PuTTY. My next test after this one will be to use a different terminal app.

Thanks,

Derek

[droberson]

Hey Sigurd,

Can you not try it on Windows 11? Could be a driver thing. I don't have a Linux machine to test with.

Is there a way for me to get debug logs from the nRF5340 on the nRF9151DK?

Thanks,

Derek

[Sigurd Hellesvik]

droberson said:

Can you not try it on Windows 11? Could be a driver thing. I don't have a Linux machine to test with.

Can do.

droberson said:

Is there a way for me to get debug logs from the nRF5340 on the nRF9151DK?

No, you can not get logs from the Interface chip.

I was suggested that you try this:

"nrfutil device x-update-debug-probe-firmware", maybe updating the Interface chip can fix this

[droberson]

Hey Sigurd,

Thanks! I will try updating the interface chip Monday as I am out of the office yesterday and today.

Derek

[Sigurd Hellesvik]

droberson said:

Can you not try it on Windows 11?

It failed with Windows 11 and Putty after 2 hours.
So I am able to reproduce!

I will create an internal ticket for this.

As a workaround for you:
You can get logging out from pins on the nRF9151DK. Aka directly from the nRF9151 and not via the Interface Chip.
Then you can connect these pins to the pins of the nRF52840DK, or another UART -> USB converter.
Will this work for you?

[droberson]

Hey Sigurd,

Glad you were able to reproduce on Windows 11!

Yes, I can redirect logging to some GPIO on the DK and use a UART <-> USB converter.

Lastly. I tried updating the nRF5340 interface chip and it seems to already be updated or failed because the checksum is 0:

nrfutil device x-update-debug-probe-firmware
serial_number: <Redacted>
        checksum: 0
        versionAfterUpdate: J-Link OB-nRF5340-NordicSemi compiled Feb 11 2025 17:15:35
        versionBeforeUpdate: J-Link OB-nRF5340-NordicSemi compiled Feb 11 2025 17:15:35

I will do some research on updating the interface chip.

Thanks,

Derek

[Sigurd Hellesvik]

droberson said:

I will do some research on updating the interface chip.

Since I can reproduce this on an updated version(I think) of the interface chip, I do not think there is any reason for trying that on your side.

[droberson]

Understood, thanks for letting me know!

Derek