Issue with resuming UART1 on nRF9151 after PM suspend with BLE module

RE: Issue with resuming UART1 on nRF9151 after PM suspend with BLE module

Priyesh Shahi — Fri, 10 Oct 2025 06:24:50 GMT

Hello,
It has been over a week, and I haven’t received a reply. Could you please provide an update?

RE: Issue with resuming UART1 on nRF9151 after PM suspend with BLE module

Achim Kraus — Tue, 07 Oct 2025 04:54:06 GMT

You're welcome.

RE: Issue with resuming UART1 on nRF9151 after PM suspend with BLE module

Priyesh Shahi — Tue, 07 Oct 2025 04:45:02 GMT

Thank you for your suggestion! I tested my code on the nRF9151 DK using a UART2USB TTL adapter, and the UART is working properly. I was able to send a few commands via TTL, and my code processed them as expected. So it seems the UART, along with the suspend and resume logic, is functioning fine.

It might be that there’s some issue with the ANNAB112 module itself.

Thanks again for your help!

RE: Issue with resuming UART1 on nRF9151 after PM suspend with BLE module

Achim Kraus — Mon, 06 Oct 2025 09:56:53 GMT

I'm just an other user and no Nordic engineer.

But I consider, that you will need the UART traces to see, if the nRF9151 or the ANNAB (ublox ANNA B?) isn't working as expected. Without that UART traces I don't see, how someone will be able to help you.

(For those UART traces you will need the 2 channel or 2 1 channel UART2USB TTL adapters as I wrote above.)

RE: Issue with resuming UART1 on nRF9151 after PM suspend with BLE module

Priyesh Shahi — Mon, 06 Oct 2025 09:49:24 GMT

Thank you for your input! I’m not seeing any UART errors related to the configuration, so that seems fine. However, my ANNAB module still isn’t getting configured properly. Could you please advise on how I might resolve this issue?

RE: Issue with resuming UART1 on nRF9151 after PM suspend with BLE module

Achim Kraus — Sun, 05 Oct 2025 17:48:13 GMT

Not sure, why you get these results.

About the uart_config_get():

Did you enable the required CONFIG_UART_USE_RUNTIME_CONFIGURE ? If not, try that ;-).

It's long ago, that I was common with debugging UART issues. What helped me in that past was a 2 channel UART2USB TTL converter (or 2 single channel). The TTL level must match your GPIO level (e.g. 3.3V). Connect the RXs of the 2 Channel UART2USB with both UART (rx/tx) you want to debug. That should make it visible, what's going on.

As I wrote, I would assume some lost or crippled bytes, and a retransmission should help here. Crossing the fingers.

RE: Issue with resuming UART1 on nRF9151 after PM suspend with BLE module

Priyesh Shahi — Fri, 03 Oct 2025 04:08:55 GMT

[quote userid="5203" url="~/f/nordic-q-a/124734/issue-with-resuming-uart1-on-nrf9151-after-pm-suspend-with-ble-module/550413"]

You accept 100x more than it should be, at least considering the nRF9151 (~7µA).

[/quote]

When I call system_off(), the current drops to around 5 µA, since most of my peripherals are off. Without this, the consumption is about 700 µA (after suspending UART1), which is still better than the 7 mA I had before. The 700 µA draw mainly comes from two sensors on I²C. One of them, the LIS2DW12, requires continuous power. I can’t power it off because it loses its configuration and only outputs 0 after wake-up. So most of the 700 µA consumption is due to this sensor.

In my code, if I don’t call pm_device_action_run(uart_dev, PM_DEVICE_ACTION_SUSPEND) and let it run as before, my BLE module works fine. But when I call suspend and then resume, it stops working.

I have two UARTs in my application: UART0 for debugging and UART1 for the BLE module.

I am also suspending the Zephyr console, and after resuming it.

RE: Issue with resuming UART1 on nRF9151 after PM suspend with BLE module

Priyesh Shahi — Fri, 03 Oct 2025 03:54:35 GMT

annab112

RE: Issue with resuming UART1 on nRF9151 after PM suspend with BLE module

Achim Kraus — Thu, 02 Oct 2025 06:19:37 GMT

[quote userid="129185" url="~/f/nordic-q-a/124734/issue-with-resuming-uart1-on-nrf9151-after-pm-suspend-with-ble-module"]the current drops to ~700 μA, which is acceptable[/quote]

You accept 100x more than it should be, at least considering the nRF9151 (~7µA).

I frequently use pm_device_action_run(uart_dev, PM_DEVICE_ACTION_SUSPEND) and pm_device_action_run(uart_dev, PM_DEVICE_ACTION_RESUME). After resume the first bytes may be lost or crippled, but a "retry" usually solves that.

I'm not aware, that the UART needs to be explicitly reconfigured after suspend/resume.

RE: Issue with resuming UART1 on nRF9151 after PM suspend with BLE module

Hakon — Wed, 01 Oct 2025 11:43:05 GMT

Hello,

what BLE chip are you using?