Api.system.sleep.lora(1000) puts the whole board to sleep

Hello guys,
i was trying to understand the behavior of the power save mode and ran into some issues or maybe i miss understood the API’s usage.

This API seems to put the Whole board to sleep api.system.sleep.lora(10000) for example 10sec instead of just putting the Lora Chip to sleep if i understood it correctly… so as of now it no different than using api.system.sleep.cpu(10000) or api.system.sleep.all(10000) they all seem to behave the same exact way…

here is a test code:

void loop()
  Serial.printf("\n Try to put lora chip to sleep for %ums..\n", 10000);
  Serial.printf("\n This should appear instantly after calling the above);
  Serial.printf("\n Try to put board to sleep for %ums..\n", 10000);
  Serial.println("Wakeup after 10 seconds..");

if you ran the above code you will notice that as soon as the call to api.system.sleep.lora(10000); the whole loop is blocked for 10 seconds and only after 10 seconds it will continue to work which i think is not the right behavior…

my guess is the firmware is using semaphores in the code that causes the whole loop to block when calling those API which shouldn’t be the case at least with sleep.lora, i think the team should use a timer instead.

Edit: i also noticed that sleep.cpu and sleep.all have the same exact power saving impact on the chip so how are they different? both yield to around 2uA…


Hello @JayjJay

Is this on RAK4631-R or on RAK3172 or on both?

I will run a quick test and report it to our R&D team if I can confirm the problem.

Hi This was tested in The RAK3172

I can also confirmed this. Also, when testing SPI communication, I noticed module wake up but then stop, I cannot reprogram module and I get “Detect baudrate fail, can not get the baudrate” in Arduino IDE. The module still execute the custom RUI3 code but stop after wake up, how can I get the module to reprogram? or re-flash the original firmware?

The problem is the same on RAK4631-R and RAK3172. The R&D team is looking into it.

Try double push reset button to force the module into bootloader mode, then try to flash.
Or if you can still type AT commands, try to type AT+BOOT to get into bootloader mode.

Thank you, at+boot does the trick.

Would you please give us updates on this?


The R&D team is looking into it.

That’s all I have for now.


I saw today in the project list the issue is marked with highest priority.
But no feedback yet about the solution.

1 Like

Thank you for the updates, i really hope the team will have this fixed ASAP as our development on the module is currently suspended due to this highly needed feature…

looking forward to a speedy fix !


Might be that we release it first in a staging version of the BSP. I will let you know as soon as we have something to test.

1 Like

Hello there,
is there any progress with this?


Still waiting for the test build.
I will post here as soon as got news.

But this version is in staging, not sure when official release will be.

Hi Bernd, apologies for bumping this post, but this functionality is critical to my application as well, trying to wake the CPU/LoRa chip once it sees UART data start to come in.

Will this fix be published soon, or is there another place where we can download the fix in the meantime? Thanks!

Sorry dropped the tag @beegee

Sorry @cmod
I still have no release date for the bug fix. Waiting for the next release impatiently as well.

Understandable, in any case thank you for letting me know. I’ll stay tuned!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.