How to get <340uA in deepsleep for DISCO_L072CZ_LRWAN1

[sillystudent96]

Hi LoRaWAN experts,

I am trying to get my LoRaWAN application running with the lorawan-mbed-os-example (latest version of Jan, 2019, Board: DISCO_L072CZ_LRWAN1) and I'm impressed so far.
Everything works fine except the sleep modes. The control of the sx1276 works perfectly fine (<1uA in sleep) but i can't get the controller current below ~340uA. The tracing output looks good (~99% of the idle time in deepsleep), LPTICKER set on RTC, MBED_TICKLESS activated and the low-power-timeout in radio driver is set. In comparison I can reach about 8 uA with an easy mbed-os program (e.g. mbed-os-blinky). I also tried some of other things but nothing worked. What am I doing wrong?

Thank you for your help!

Kind regards.

[ciarmcom]

ARM Internal Ref: IOTCELL-1676

[hasnainvirk]

@sillystudent96 You may need to consult the data sheet of the MCU in this regard. Print out the value of SystemCoreClock and you will know what clock speed your MCU is running on. The clock speed determines the active power state of the MCU. A word of caution though: Do not slow down too much.

I had recently been playing around with a board clocked at mere 4MHz and that ended up interrupting smooth flow of the application because a large processing delay was introduced. I could cover it up though by using an insanely high error compensation (about a 100ms) for the stack computations. I am aware of the fact that the 4MHz clock is probably the boot mode clock only (as that particular board can be clocked to about 90MHz), and the people would actually be using much higher clocks. But there are always some adventurers :) who wouldn't mind going ultra ultra low power.

Alright, back to your question:
You can reduce power consumption by communicating less often for a starter.
As said above, consult datasheet for activating MCU low power modes. I am not aware of a standard method in Mbed OS that can change power mode and Clock speed of the MCU. You need to dig through HAL code under targets/ directory.
In blinky example, no other peripherals are on and there is almost no processing overhead. With LoRaWAN stack if you would change the application to be less frequent you will see better results in power consumption.

[janjongboom]

@sillystudent96 This might help as well to bring the STM32 into standby mode. You'll need that for lowest power. https://github.com/janjongboom/stm32-standby-rtc-wakeup. Note that it will not retain RAM.

[sillystudent96]

First of all thank you guys, I'm glad you help me!

@hasnainvirk I digged through the data sheet and realized that the controller has to be in active running mode during deepsleep. I am actually playing with the clock speeds but i don't think thats the core of the problem. Also, I'm waking up just every 10 minutes to reduce overall power consumption but 340 uA during sleep is simply too much. What I am trying to understand is: Why is there such a big difference between deepsleep in the blinky example and deepsleep in the LoRaWAN example (even with the LoRaWAN stack overhead)

@janjongboom I tried the library and as well as your solutions for greenhouse example but I had no success. What worked for me is calling ev.queue.call_every(TX_TIME, &send_message) in the connect event and wait(sleep_time) right at the end of the send message function. This way I'm achieving the 8uAs for that specified wait time. This solution however would require to calculate the sleep time dynamically, depending on the LoRaWAN-Stack's specific state and im at a loss on how to approach this. Ideally, i would not need to worry about sleep times and just let the OS handle going into the deepest possible sleepmode whenever possible. Any hints on how to approach this?

Kind regards

[janjongboom]

@sillystudent96 I've been using the normal sleep API and that works fine for LoRaWAN... Device shows deepsleep for most of the time. It feels that there's some peripheral blocking sleep? Could you look at the sleep stats and see if there's any sleep locks active?

[DaedalosSG]

Hey guys,

I have almost the same problem. I am using the DISCO-L072CZ-LRWAN1 for my project. Similar to @sillystudent96 approach i want to reduce the power consumption as much as possible. Not modifying the mbed-os-example-lorawan there is an average current of 330µA (Sending every minute and Duty_cycle is off). Further i set lpticker_lptim to 0 in the targets.json. That means i use RTC wakeup timer. Using the tracer i got the following results:
Uptime: 41871704
idle time: 41693479
sleep time: 11715
depp sleep time: 41681764
Thus, it seems like that deepsleep is working just fine and is not blocked, but still i am not getting lower than 330µA. Shouldn't the OS go lower than that by itself? And if not, what do i have to add in code to get close to 8µA. @janjongboom standby is an option of course, but i would prefer not to clear all states.

Thank you for your help!

Kind regards

[hasnainvirk]

@DaedalosSG You must not disable duty cycle because you are breaking regulation here by doing so. Turning off duty cycle is only allowed during Device Certification process under controlled environment.
Answering your question, as I had tried before to @sillystudent96, you must change how the application is behaving. Because the way application is written, it will use every opportunity to transmit, i.e., it will send as fast as it can. That means essentially the application is not letting you sleep properly. As soon as the state machine is done performing a task, it goes into another cycle. You got to understand that. Now that I can see that you are transmitting after a minute or so and trying to average out the power consumption. Here you need to understand that MCUs run on several power states e.g., lowest power mode could be the Boot Mode in which an MCU runs on a staggeringly low clock speed. To clock down the device to consume an average current of 8 uA you got to hack around the MCU porting code. This code is mostly contributed to Mbed OS by our vendor partners. It would be actually very interesting to come up with a standard mechanism in Mbed OS to clock up or Clock down an MCU, I would let the architects know. If you wish to do that yourself, please look into the porting layer of the particular board you are using and consult the data sheet. That will enable you to clock down the MCU which will in turn help you achieve lower power state near to your desired value.

[hasnainvirk]

@sillystudent96 Actually you have a point here. It kind of slipped through when I was going through your text previously. We may need to check the core timer code for the stack if there is anything blocking there and how is it effecting. Because if you can see a significant drop in power consumption using call_in() method over the event queue, then there must be something in our timer instance (the LoRaMacTimer class) which may be locking the system and preventing it to go for deep sleep. In @DaedalosSG's comment, I can see the idle time and deep sleep time are almost equal, that can't be right. Either there is something wrong with the configuration you guys are using or there is a real problem. I will investigate that and come back to you guys when I have an answer.

[janjongboom]

@bulislaw @0xc0170 You have been working on the deepsleep APIs, right? Any idea what might be going on?

[YoannBo]

@sillystudent96
340uA sounds like the debugger is likely to be still activated when MCU enters sleep mode. In I-CUBE-LRWAN this in done in file debug.c
1/ disable debug under sleep modes:

  __HAL_RCC_DBGMCU_CLK_ENABLE( );
  HAL_DBGMCU_DisableDBGSleepMode( );
  HAL_DBGMCU_DisableDBGStopMode( );
  HAL_DBGMCU_DisableDBGStandbyMode( );
  __HAL_RCC_DBGMCU_CLK_DISABLE( );

2/ disable sw interface (debug pins) PA13 and PA14 by setting them in analog input:

 GPIO_InitTypeDef GPIO_InitStructure ={0};
  
  GPIO_InitStructure.Mode   = GPIO_MODE_ANALOG;
  GPIO_InitStructure.Pull   = GPIO_NOPULL;
  GPIO_InitStructure.Pin    = (GPIO_PIN_13 | GPIO_PIN_14);
  __GPIOA_CLK_ENABLE() ;  
  HAL_GPIO_Init(GPIOA, &GPIO_InitStructure);
  __GPIOA_CLK_DISABLE() ;

[sillystudent96]

Hey guys, thanks for your help. For testing, I switched back to a L4 host controller and put the LoRaWAN module into AT Command mode (using st's at-modem firmware). Of course, thats not representative for the LoRaWAN stack itself, but I got the low power modes running with the mbed os 5 on the L4 - and it worked as it should. Now I am waiting for my sx1276 and sx1272 dev boards and will then test the LoRaWAN stack on the L4. I also had some issues with the low power modes of the Nucleo L433RC-P as well: The sleep current was about 100uA, as opposed to the microamps described in the datasheet. A floating input pin was the issue there. I fixed it by pulling PB_3 low (connected to SWO on the nucleo board). Maybe some other boards also have issues like that.

[0xc0170]

@sillystudent96 thanks for the feedback!

cc @ARMmbed/team-st-mcd

[sillystudent96]

Hey guys, so I received my SX1272MB2DAS shield and the SX1276MB1MAS shield and connected them to the well known Nucleo_L476RG (here I know that the sleep modes work). I made the new pin mapping in the mbed_app.json for the Nucleo_L476RG, autogenerated a new DEVEUI by TTN and tried to run the code on the L4. Now I have the problem that the program is stucking while joining. "Connection - In Progress ..." is the detailed message for both the sx1272 and the sx1276. The device isn't joining and I can see no gateway traffic. Anybody an idea how to continue here?

[hasnainvirk]

@sillystudent96 Sounds like a pin clash .. Can you please share your json file and any trace ?
Most probably you will be getting Radio TX timeout which means radio was unable to transmit. That's why you are not seeing any traffic at the base station.