No output to uart after sleep

[ms1963]

Maybe, it is just an issue on macOS. When I am using PicoDemoSleep on the Mac (using minicom or any other app as serial monitor), there will be no output to the uart anymore (such as printf) after sleep is over. Seems as if uart has been disabled or changed due to sleep mode. The LED is turning on and off, though => program works as expected.

[ghubcoder]

@ms1963 Hi there, how are you connected from the mac to the pico, I'm assuming via USB?

I've seen that the USB behaves strangely when sleeping, it doesn't seem to re-initiate the connection after the pico recovers from sleep. When testing I have been using the UART method connected directly to another Pi, using GP0 and GP1 as in this diagram.

I also found that I needed to comment out this line: https://github.com/ghubcoder/PicoSleepDemo/blob/55b557218fcb22b67c441b362d1c8fae0c4a5605/CMakeLists.txt#L15

At least I think that was causing my pico to hang after a while ( say, 10 occurrences of sleeping, something like that) when it was just running standalone, with no connetions to the Pi. In addition I also removed any printf statements from my code.

I'd like to test this further when I get chance to work out what is causing it to hang, but certainly I've had it run for weeks on battery power without it hanging using this method.

[ms1963]

Dear ghubcoder,

Thanks for your comment.

I have used USB indeed and also tried the functionality to disable USB during sleep and then re-enable it after sleep, but without success. And I have experienced the problem with the Pico hanging up even when I am using the board standalone, i.e., unconnected and powered from battery.

In the meantime I‘ve written an example that includes a C++ class for easier integrating sleep functionality into own programs. See https://github.com/ms1963/SleepyPico

I have also opened an issue in the Pico-Extras-Repository which has not been addressed so far.

[RayNieport]

Same issue here. I've tested with USB and UART (Windows 10). USB stops working after sleep, though the LED keeps blinking for a short time until it hangs. UART works fine for a while but eventually the whole system hangs just like with USB. @ghubcoder can you confirm that altering CMakeLists.txt and removing print functions fixed this hanging issue? I can't really remove all prints as stdio is important for my project.

[ghubcoder]

@RayNieport Try removing this line:

https://github.com/ghubcoder/PicoSleepDemo/blob/55b557218fcb22b67c441b362d1c8fae0c4a5605/main.c#L53

For me at least that stops it from hanging. Other wise it hangs after 3 sleep cycles.

[ms1963]

Thanks a lot. I will try it.

Prof. Dr. Michael Stal, Auenstraße 34, D-80469 München Chefredakteur/Editor-in-chief JavaSPEKTRUM Professor @ University of Groningen

Am 13.08.2022 um 15:54 schrieb ghubcoder @.***>:

 @RayNieport Try removing this line:

https://github.com/ghubcoder/PicoSleepDemo/blob/55b557218fcb22b67c441b362d1c8fae0c4a5605/main.c#L53

For me at least that stops it from hanging. Other wise it hangs after 3 sleep cycles.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[illness072]

Hello. I had the same problem. It seems that the problem is that in the loop stdio_init_all()→stdio_usb_init()→irq_add_shared_handler(), I keep adding the collection of IRQ handlers without releasing them.

https://github.com/raspberrypi/pico-sdk/blob/6a7db34ff63345a7badec79ebea3aaef1712f374/src/rp2_common/hardware_irq/irq.c#LL215C12-L215C12

It may be correct to properly free these IRQ handlers before Deep Sleep, but as @ghubcoder says, simply removing stdio_init_all() in the loop will also avoid the crash. However, in this case, the UART log will not work properly, so running stdio_uart_init() instead will cause the messages to be output properly.

(I'm using machine translation, so sorry if it contains strange English expressions.)