STM32WL55JCI7. Strange behavior RFBUSYMS bit

[MEvdo.1]

Hello.

I purchased development board Nucleo-WL55JC2 based on STM32WL55JCI7 and am developing software for wireless data transfer.

The documentation (RM0461) says:

4.7.1 Startup mode

At POR or after a sub-GHz radio reset, the Startup mode is entered. BUSY is set. When

internal supply and clocks become available, the sub-GHz radio enters Sleep mode.

4.7.2 Sleep mode

In Sleep mode ... BUSY is set

...

Following a POR sub-GHz radio reset, the Deep-Sleep mode is entered from Startup mode.

...

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)

• on a request from the sub-GHz radio RTC timer generating an end-of-count event

(corresponding to duty cycled operation)

Examining the behavior of the MCU, I found that to clear RFBUSYMS,RFBUSYS bits ( PWR_SR2 register) it is enough to clear RFRST bit (RCC_CSR register). Thus, the documentation contains an inaccuracy. I'm right?

Also I found that after the RadioSPI exchange, when the NSS bit is set, the RFBUSYMS bit remains high, although the busy bit RFBUSYS is cleared.

Tell me, please, what could be the matter here?

[JKo]

I force a reset by holding RFRST bit high for 100μs.

After POR the RFRST bit must be brought low to get the radio into Startup then Sleep mode.

Then SPI_NSS is brought low for 20μs to bring the radio out of Sleep.

I haven't tested RFBUSYMS nor RFBUSYS bits after RFRST only.

For the Radio SPI I found that the RFBUSYMS is NOT an OR of the SUBGHZSPI_NSS and RFBUSYS as indicated in RM0453 Figure 23 for the subsequent commands.

The RFBUSYMS remains high long after any SPI register read or write and SPI_NSS was cleared.

The STM32CubeMX generated code shows that the RFBUSYMS is actually used to mask the RFBUSYS status. AND is used so if either is clear then the next command can be sent.

The documentation is also not clear on which commands do not have an expected radio busy indication.

[JKo]

Did you ever find a better answer or solution to the RFBUSYMS status bit? The CubeMX code does not agree with the documentation and effectively ignores the fact that RFBUSYS may remain low up to 600ns after NSS is set high.

[jpnorair]

One possible workaround is to wait for the WRFBUSY flag to assert.

Otherwise, the 600ns lockout time for the RFBUSYS is about 29 clocks at 48 MHz, which is typically exceeded between calls to SPI activation routine. You can check RFBUSYS before setting NSS low, rather than after.