New (v1.5.0) LoRaWAN_End_Node_LBM example draws much more current than previous

[JHCarter]

I have been working with the single core LoRaWAN_End_Node example application on a B-WL5M-SUBG1 board with good success.  With STM32CubeMx v6.16.0, WL Firmware 1.4.0, I see a current draw of under 2uA between transmissions.

Last week I upgraded STM32CubeMx to v6.17.0 which in turn upgraded the WL Firmware to 1.5.0, changed the end node example to use the LBM library rather than the LmHandler for managing the radio, and changed the example application name to LoRaWAN_End_Node_LBM.  The application functionality is good but the power consumption jumped to around 80uA between transmissions.

In both cases I configured pullups in the USART2 pins (PA2, PA3).

I can alternate between these two versions of the application on the same board and the results are very consistent.

Has anyone else seen this and does anyone have any suggestions?

[Imen.D]

Hello @JHCarter ,

Check the hardware configuration (VDD_APP, UART2 pullups) to ensure that it is properly powered during measurement.

Try also using the latest firmware package STM32CubeWL v1.5.0.

[JHCarter]

Hello Imen.D

My hardware test setup is a B-WL5M-SUBG1 board with nothing attached to the CN3 Debug connector and powered by a bench supply connected to CN5 (E3V3).  In order to use the 3V3 supply, I made the modifications to the board as specified at the bottom of Sheet 8 of the MB1779 Rev B-02 schematic.  I am measuring the current across JP1 with a Nordic Semiconductor Power Profiler Kit II.

I have two test applications that I have run on the same test setup. 

The first is the LoRaWAN_End_Node example generated by STM32CubeMX v6.16.0 which uses STM32CubeWL v1.4.0.  In STM32CubeMX I configured pullups on PA2 (USART2_TX) and PA3 (USART2_RX).  I also configured a pullup on PA15 as that was mentioned in a previous post about power consumption on this board.  This application draws under 2uA between transmission cycles.

The second is the LoRaWAN_End_Node_LBM example generated by STM32CubeMX v6.17.0 which uses STM32CubeWL v1.5.0.  In STM32CubeMX I configured pullups on PA2 (USART2_TX) and PA3 (USART2_RX).  I also configured a pullup on PA15 as that was mentioned in a previous post about power consumption on this board.  This application draws approximately 80uA between transmission cycles.

So you can see I have configured pullups on USART2 as you suggest.  I am not sure exactly what you mean by the "hardware configuration of VDD_APP".  If you can explain where I can check that configuration I will do it.

Thanks for your help.

[JHCarter]

It looks like the issue is with the antenna switch.  In the STM32CubeWL v1.4.0 version of the application the antenna switch is configured to TX (high or low) when transmitting, RX when receiving, and OFF the remainder of the time.  In the STM32CubeWL v1.5.0 version of the application the antenna switch is configured to TX (high or low) when transmitting and RX for the rest of the time.  It is never configured OFF.

This is the v1.5.0 code that controls the antenna switch.  You can see that the switch is set to LP, HP, or RX.  There is no path that sets it to OFF.

Middlewares/Third_Party/SubGHz_Phy/lorawan/radio_drivers/sx126x_driver/src/sx126x.c beginning at line 1281:

sx126x_status_t sx126x_set_ant_switch( bool is_tx_on )
{
  RBI_Switch_TypeDef state = RBI_SWITCH_RX;

  uint8_t paSelect= RFO_LP;

  if (is_tx_on)
  {
      if (paSelect == RFO_LP)
      {
          state = RBI_SWITCH_RFO_LP;
          if ( 1U == RBI_IsDCDC() )
          {
            uint8_t modReg;
            HAL_SUBGHZ_ReadRegisters( &hsubghz, SUBGHZ_SMPSC2R, &modReg, 1 );
            modReg&= (~SMPS_DRV_MASK);
            HAL_SUBGHZ_WriteRegisters( &hsubghz, SUBGHZ_SMPSC2R, (uint8_t*)&modReg, 1 );
          }

      }
      if (paSelect == RFO_HP)
      {
          state = RBI_SWITCH_RFO_HP;
      }
  }
  else
  {
      state = RBI_SWITCH_RX;
  }
  RBI_ConfigRFSwitch(state);

  return RADIO_STATUS_OK;
}

For testing I changed the "else" case above to set state to RBI_SWITCH_OFF rather than RBI_SWITCH_RX.  I expected that it would be unable to receive and therefore would never join the network but I could at least monitor the current draw and see if the antenna switch could be the problem.

What I found was that indeed the current draw dropped from 80 uA to 1.4 uA and surprisingly the RX path worked just fine.  

I haven't been able to find an internal schematic for the STM32WL5MOC so I don't really know what the impact of this change is on the antenna switch itself.

I believe I have demonstrated that the LoRaWAN_End_Node_LBM application as delivered in v1.5.0 is not viable for low power operation.  So at this point I have two questions for STMicro:

1. Is the code change I made an acceptable solution for now?
2. Will you make the necessary modifications to the LoRaWAN_End_Node_LBM code to enable it to work in a low power application?

[JHCarter]

I have answered my first question.  The code change I made, setting the antenna switch to RBI_SWITCH_OFF rather than RBI_SWITCH_RX when it is not transmitting, is not an acceptable solution.  I modified my lora_app.c to print out the RSSI on downlink messages received and the difference is significant.  In my test setup the B-WL5M-SUBG1 board is less than two meters from the gateway.  With the original code (RBI_SWITCH_RX) I see an RSSI of -30.  With my modification (RBI_SWITCH_OFF) I see an RSSI of -49.  

So is there any way to use LoRaWAN in STM32CubeWL-v1.5.0 in a low power situation?  If not, can we expect a fix in the near future?

[JHCarter · Accepted solution]

I believe I have found an acceptable solution.  In the file radio_planner.c the function rp_callback() begins at line 479. At lines 547 and 562 there are calls to the function ral_set_sleep().  The first is in an if clause and the second is in the corresponding else clause, so one or the other will definitely be called.  Among other things the ral_set_sleep() function sets the antenna switch to OFF.  But subsequently at line 567 the function ral_set_antenna_switch() is called with the second argument of FALSE.  This results in the antenna switch being set back to RX as discussed above.  Since the radio has already been put to sleep by the call to ral_set_sleep() I cannot see the benefit of this function call.  I have commented out line 567 and everything works as expected, including a current draw of under 1.5uA between transmissions.

There are several other places in the code where ral_set_antenna_switch() is called immediately after ral_set_sleep() but this is the only one that I have found to affect the current draw.

So for now I am moving forward.  I would still be grateful for any comments, suggestions, or observations on this issue.