STM32WL SubGHz with STOP2 mode - unexpected current after first wakeup

[CLind.1]

I'm trying to get a handle on using the Sub Ghz middleware along with the processor's low power modes. I've configured an X-NUCLEO-LPM01A to power the NUCLEO-WL55JC, following the instructions from the STM32WL webinar, so I can take some measurements.

I'm using LPTIM1 to generate an interrupt every 4 s where I then transmit a short packet with the radio configured for FSK modulation. The radio is set to sleepmode in the TX complete callback. and the processor set to enter stop 2 mode again. For the first time the board is powered down in STOP 2, I measure the expected 2.5 uA, but as soon as the first radio packet is sent, the current doesn't go below 650 uA. (See the attached screenshot)

Does anyone have any insight as to what it could be? It seems to me that something is preventing the processor from entering the STOP 2 mode again. Could it be an unhandled interrupt? I also can't tell if the radio is set to sleep successfully after that first transmit.

Any assistance would be greatly appreciated

[YBOUV.1]

Hello,

Maybe the radio remains in standby mode instead of sleep mode,

Can you try to put the Radio in sleep mode after a Radio interrupt?

e.g. Radio.Sleep( );

As a tip. The supply you are monitoring is the supply of both the radio and the system(VDD_MCU=VDD_RF + VDD_SYS). This is useful to discriminate where the current is sunk from.

The supplies of the radio and the system (not radio) can be monitored separately on the Nucleo :

monitoring System-> close JP1, mount JP5 and open SB27

monitoring RF -> close JP1, mount JP2 and open SB28

 

Best regards

[PGoud]

Hello all,

I'm getting the same kind of behavior using HAL SUBGHZ, with STM32WL with LoRa mode.

In fact my Tx complete interrupt callback try to make a Sleep (using the subGHz Sleep API from Semtech middleware).

But I think that the RF part get back from sleep mode immediately as, at the end of Tx complete interrupt from

HAL_SUBGHZ_IRQHandler() 

there is this line:

...
 /* Clear SUBGHZ Irq Register */
 (void)HAL_SUBGHZ_ExecSetCmd(hsubghz, RADIO_CLR_IRQSTATUS, tmpisr, 2);
}

Which, I think, make a new SPI Acces to RF part, hence, getting it back in Stanbye mode ... Cf RM0453 rev2 page 171:

"Exit Sleep mode can be done:

• on a firmware request via the sub-GHz radio SPI NSS signal (keeping sub-GHz radio

SPI NSS low for at least 20 μs)"

Could anyone confirme this fact ?

[PGoud]

An update.

I tried to clear the interrupt register at the beginning of HAL_SUBGHZ_IRQHandler(), and my RF part is now correctly set to sleep mode after any of my TX, Rx or any other interrupt call backs that need it ...

Please do not hesitate to comment if that may not be the good palliative ?

{
 uint8_t tmpisr[2] = {0};
 uint16_t itsource;
 
 /* Retrieve Interrupts from SUBGHZ Irq Register */
 (void)HAL_SUBGHZ_ExecGetCmd(hsubghz, RADIO_GET_IRQSTATUS, tmpisr, 2);
 itsource = tmpisr[0];
 itsource = (itsource << 8) | tmpisr[1];
 
 /* Clear SUBGHZ Irq Register */
 (void)HAL_SUBGHZ_ExecSetCmd(hsubghz, RADIO_CLR_IRQSTATUS, tmpisr, 2);
 
...

[YBOUV.1]

Hi @PGoud​,

The radio IP is probably in standby mode, which is the default radio low power mode after any RF activity is completed.

You should put it in sleep mode with the following:

Radio.sleep();

[PGoud]

Hello,

Thanks for the answer. But that's indeed what I could see.

The question is about the palliative I use.

ie: I modify the HAL_SUBGHZ_IRQHandler() to keep any radio state that would have been fixed during IRQ call backs.

Please see my previous post.

Maybe that should be a modification to do in the generic HAL_SUBGHZ_IRQHandler().

What do you think about that ?

BR

[YBOUV.1]

I missed, I already answered smthg about the standby and sleep...

It is not clear to me what is your issue. could you described the code sequences:

1- that are not OK ?

3- that are OK

[PGoud]

1-The default HAL_SUBGHZ_IRQHandler() clears the interrupt register at the END. Then When an Interrupt call back process set the Radio to sleep, the last instruction that clears the interrupt make an SPI access to the RF part hence set it in standby mode !

2-Clear the interrupt CR register juste after having read it at the BEGINING of the interrupt solve this. I just wanted an "opinion" about this palliative AND maybe that it could be taken in account for a next version of HAL_SUBGHZ ?

[YBOUV.1]

Hi @PGoud​ ,

I think this would be ok,

I will check internally what we can do