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]

Understood, thanks for letting me know!

Derek

[droberson]

Hey Sigurd Hellesvik  ,

Was this issue ever resolved? I encountered it again today by accident which refreshed my memory that this ticket was still open.

Thanks,

Derek

[Sigurd Hellesvik]

Hi Derek,

It has not been resolved yet, no.

Now that you reminded me of it, I did give our internal ticket a little push as well, so hopefully there will be some progress on this soon.

[droberson]

Ok no rush, thanks for the update!

Derek

[Elfving]

Hi Derek, I'm taking over this case from SIgurd.

Are you still seeing the issue? I do not think I am, and I wonder if maybe the later ODB FWs might have fixed it.

Regards,

Elfving

[droberson]

Hey Elfving,

We have moved all of our development to our custom board now, so I am no longer using our nRF9151DK kits. Make sure you are testing on Windows 11 as Sigurd was unable to reproduce it on Linux.

It would be nice to know the environment you are using in which you are unable to reproduce it. Such as:

• PC OS
• nRF9151DK version
• ODB FW version
• Terminal software (PuTTY or which one?)

Once confirmed, we can close this ticket.

Thanks,

Derek

[Elfving]

I see, good that it is not something that is bothering you at the moment. I was using realterm instead of PuTTY, and a newer ODB FW, but otherwise everything is the same. I'll try it again using PuTTY.

Regards,

Elfving

[droberson]

Hey Elfving,

PuTTY works fine for me on our custom board, so I doubt you will be able to reproduce it with that change. It most likely is the ODB FW. We can close the ticket, and if I see the issue again in the future, I can create a new ticket and link it to this one.

Edit: If you would like me to re-test on my end with a specific ODB firmware, let me know the version and I can run this test sometime next week.

Thanks,

Derek

[Elfving]

No that sounds like an idea. Updating to the newest ODB FW is the recommended approach in any case; there is no reason to hold on to an old one where this issue also occurs.

Let us know if there is anything else!

Regards,

Elfving

[droberson]

I set up a test to run over the weekend using the same blinky sample on SDK / Toolchain 2.9 with a 0.9.0 nRF9151DK and PuTTY

Previous ODB (I think it's OBD not ODB?) firmware that I tested with (and was the latest available at the time): J-Link OB-nRF5340-NordicSemi compiled Feb 11 2025 17:15:35

New OBD firmware: J-Link OB-nRF5340-NordicSemi compiled Jul  8 2025 10:15:34

My kit has been running for 36 hours and is still going strong. Thus, it looks like some OBD firmware between Feb 11 and July 8 resolved the issue.

Thanks,

Derek