UART not working after PM_DEVICE_ACTION_SUSPEND

[Ryan S]

Hi there, 

I have been trying to implement a low-power mode that basically suspends UART, I2C, etc before entering sys_poweroff() when critical battery level is triggered. 

As a test, I used the following main() script to suspend console  - something that is physically observable to me without disabling the GPIO wakeup source

My goal was to resume it when a GPIO interrupt is triggered - which will later be my charging IC interrupt when device is connected to power. 

int main(void)
{
	printk("system starting...\n");

	if (!device_is_ready(button.port))
	{
		printk("button device not ready\n");
		return 1;
	}

	if (!device_is_ready(led.port))
	{
		printk("LED device not ready\n");
		return 1;
	}

	gpio_pin_configure_dt(&led, GPIO_OUTPUT_ACTIVE);
	gpio_pin_set_dt(&led, 1);

	// configure button with interrupt
	gpio_pin_configure_dt(&button, GPIO_INPUT);
	gpio_pin_interrupt_configure_dt(&button, GPIO_INT_EDGE_TO_ACTIVE);
	gpio_init_callback(&button_cb_data, button_pressed_isr, BIT(button.pin));
	gpio_add_callback(button.port, &button_cb_data);

	printk("entering simulated low power mode\n");
	printk("console will suspend. Press button to wake up\n");

	// suspend UART console (to simulate print being "lost" during sleep)
	if (pm_device_action_run(uart_console_dev, PM_DEVICE_ACTION_SUSPEND) == 0)
	{
		printk("console suspended. This should NOT be visible\n");
	}
	else
	{
		printk("failed to suspend console device\n");
	}

	// simulate "sleep" by waiting for wake-up event
	while (!wake_up)
	{
		k_sleep(K_MSEC(100)); // light sleep
	}

	// resume UART console
	pm_device_action_run(uart_console_dev, PM_DEVICE_ACTION_RESUME);

	printk("system resumed from low power mode\n");
	gpio_pin_set_dt(&led, 0);

	return 0;
}

My issue is that I can no longer print anything to UART console, even after resuming it. 

I created a separate script for debugging that only tries to resume the console, and found that pm_device_action_run(uart_console_dev, PM_DEVICE_ACTION_RESUME) was returning:

 -EALREADY "If device is already at the requested state."

This makes sense if I didn't try to suspend it, however I am quite confused why I can no longer see serial output across re-flashing and reboot from either COM port despite UART console apparently being active

I am using nrf54L15dk on v3.1.0 SDK 

Any help would be much appreciated. Thanks

[Vidar Berg]

Hello,

It's strange that PM_DEVICE_ACTION_RESUME returns with -EALREADY when the PM_DEVICE_ACTION_SUSPEND action prior did not return any error. I did manage to reproduce it here either. Could you please try with the attached project I tested with and see if you get the same result? 

hello_world_pm_test.zip

Best regards,

Vidar

[Ryan S]

Hi Vidar, 

Thanks for your response. 

I have edited the post, but what I meant to say is that I made a separate dedicated script that only tries to resume the console - and that was the error I received.

Initially I tried the system_off() sample suggested by user Sunil vignesh above your reply, which changed nothing. I also flashed the blinky sample to see if I get any output. The issue persisted across re-flashing and rebooting. 

However I just tried monitoring serial COM4 using CoolTerm instead of through the nRF VSCode extension and was able to see the output. 

When I switched back to VSCode -  it now works. 

Strange and not really sure why that is. Usually I would expect the following message if a COM port was busy: 

"Connecting to COM4 (7s) - Opening COM4: Access denied"  

Thank you

[Vidar Berg]

Hi,

Thanks for the update. I'm not sure I fully understand the problem. The VCOM has no knowledge of the state of the UART on the nrf, so whether the driver is in an active or suspended state should not affect the ability to connect to the port. 

Ryan S said:

Initially I tried the system_off() sample suggested by user Sunil vignesh above your reply, which changed nothing. I also flashed the blinky sample to see if I get any output. The issue persisted across re-flashing and rebooting. 

Were you unable to open the port? In that case, maybe the port was acquired by another program or background process?

[Ryan S]

I thought that it might be accessed by another process, but usually I would receive the error that I outlined if it was. 

It is working now anyways. 

I have been using CoolTerm for serial since. 

I understand that the issue shouldn't have been caused by firmware

[Vidar Berg]

I see. I'm afraid I don't have a good explanation for what might have happened earlier. It's good that it's working now at least.