Hi everyone
I try to start the following application to test ultra low power mode on wp76xx module, here the code
void SwitchToLowPowerMode(void)
{
LE_INFO("************** START ULTRA LOW POWER MODE **************");
// Boot after 1000 second of shutdown.
LE_ERROR_IF(le_ulpm_BootOnTimer(1000) != LE_OK, “Can’t set timer as boot source”);
// Boot if GPIO36 voltage level is high.
LE_ERROR_IF(le_ulpm_BootOnGpio(36, LE_ULPM_GPIO_HIGH) != LE_OK, “Can’t set gpio36 as boot source”);
// Boot if GPIO38 voltage level is low.
LE_ERROR_IF(le_ulpm_BootOnGpio(38, LE_ULPM_GPIO_LOW) != LE_OK, “Can’t set gpio38 as boot source”);
But when le_ulpm_ShutDown() is called i get an error that correspond to result LE_NOT_POSSIBLE.
Than i try to enable manually this mode by do the following commands:
cd /sys/module/swimcu_pm/boot_source/
echo 100 > timer/timeout
echo 1 > enable
Than the board is shutdown and after 100s exit from low power mode. I measure the power consumption and doesn’t change. Can anyone tell me what i’m wrong?
Can you confirm the voltage levels on GPIO36 and GPIO38 at the time when le_ulpm_ShutDown()is called?
From my own experience with a WP8548 module, result codes of LE_NOT_POSSIBLE from calls to le_ulpm_ShutDown() with one or more GPIOs configured for boot are due to state of those GPIOs when the shutdown function is called.
For instance, if you configure to boot on GPIO36 when the voltage level is high and then you attempt to shutdown while the voltage level is at the same level you want it to boot on - you’ll get LE_NOT_POSSIBLE.
It sort of makes sense since the modem would shutdown then immediately boot back up, so I think it decides it’s not worth doing.
However, there are legitimate cases where you’d want to shutdown and boot on an edge-transition, say a rising-edge, and the modem will inhibit you from doing so if the voltage level is already high (this has been my experience).
It would be nice to have a _ForceShutDown() function or some method to override the ulpm logic.
Hi @Raf,
Thank you for your information. The problem was that the GPIO 36 was used from another our application to do other things. Than i used GPIO 36 just to manage ULP application and now it’s working on mangoh red development board with WP76 module. Anyway this mode don’t work on our custom device, but this is another story. I think that there is some trouble on gpio connections.
Thank you for your help.
I just tried this sample code mentioned above in a test application, but only with BootOnTimer with 120 seconds (2 min).
First it failed to execute shutdown call. As @dfrey mentioned, I stopped devMode app and tried again.
This time, the shutdown is initiated and completed. It woke up after 2 mins. (Had to do a clean build of the app, as it didn’t work initially).
Question - Not sure if any of the on-board sensors can trigger the device to wake up, before the Timeout? Or it is only the external inputs that can be programmed to wake up the device?
On mangOH Red, the light sensor is connected to one of the ADCs that is capable of waking from ULPM. By default the bmi160 interrupt lines are connected to the GPIOs that are capable of wakeup from ULPM, but in your case, you have moved those to different GPIOs. I still haven’t tried using the original GPIOs as interrupts, so I’m not sure if that’s possible. So in theory the bmi160 hardware can be left running while in ULPM and then the WP module could get woken up by an interrupt such as significant motion.