STM32WL55CCUX – SubGHz RF BUSY and 32 MHz TCXO/VDDTCXO Not Starting

[dilipraj1709]

Dear ST Community,

I am on the STM32WL55CCUX and am facing an issue with both the SubGHz radio initialization and the external 32 MHz TCXO/HSE32 clock.

I have a working STM32WL55JC1 board for comparison. The same/general SubGHz software flow works correctly on the JC1, whereas the custom CCUX board exhibits the following two problems:

1. The SubGHz radio remains permanently/continuously in the RF BUSY state.
2. The external 32 MHz, 3.3 V TCXO is not being powered through PB0/VDDTCXO, and HSERDY does not become active.

I would like ST's assistance in determining whether these two symptoms are related to the RF power/reset/TCXO sequencing, a CCUX-specific requirement, or a hardware/configuration issue.

 

This is the current analysis so far

                         JC1             CCUX

PB0/TCXO supply           Active          0 V

HSERDY                    1               0

ErrorCode                 0               0x02

RFBUSYS after init        0               1

STDBY_RC                  PASS            FAIL

[Filippo_Malleo]

Hi dilipraj1709, 

you need to figure out why the PB0 is at 0 V: firmware issue or schematic issue. 


BR,
Filippo

[dilipraj1709]

Hi Filippo_Malleo,

 

I generated the project file using the STM32CubeIDE for STM32WL55CCUx microcontroller. I also modified the SUBGRFInit() as 

 

void SUBGRF_Init( DioIrqHandler dioIrq )

{

/* Register DIO IRQ callback */

if (dioIrq != NULL)

{

RadioOnDioIrqCb = dioIrq;

}

 

/* Basic radio initialization */

RADIO_INIT();

 

/* Set default SMPS current drive */

Radio_SMPS_Set(SMPS_DRIVE_SETTING_DEFAULT);

 

ImageCalibrated = false;

 

/* Put radio in standby RC */

SUBGRF_SetStandby(STDBY_RC);

 

/*

* ============================================================

* TCXO INITIALIZATION

* ============================================================

*/

if (1U == RBI_IsTCXO())

{

printf("\r\n===== TCXO INIT START =====\r\n");

 

/*

* Configure the SubGHz radio for external TCXO.

*

* TCXO_CTRL_VOLTAGE must match the actual TCXO supply.

* For your hardware this should be TCXO_CTRL_3_3V.

*/

SUBGRF_SetTcxoMode(

TCXO_CTRL_VOLTAGE,

RF_WAKEUP_TIME << 6

);

 

/*

* TCXO trimming is not required when using an external TCXO.

*/

SUBGRF_WriteRegister(REG_XTA_TRIM, 0x00);

 

/*

* Enable STM32WL VDDTCXO output through the RCC.

*

* This enables the dedicated TCXO supply path connected

* to PB0/VDD_TCXO.

*/

LL_RCC_HSE_EnableTcxo();

 

/*

* Enable the HSE/TCXO oscillator path.

*

* Keep the CPU SYSCLK on MSI/PLL. This only enables the

* HSE path used by the radio/TCXO.

*/

LL_RCC_HSE_Enable();

 

printf("RCC->CR = 0x%08lX\r\n", RCC->CR);

 

printf("HSEBYPPWR = %lu\r\n",

(RCC->CR & RCC_CR_HSEBYPPWR) ? 1UL : 0UL);

 

printf("HSEON = %lu\r\n",

(RCC->CR & RCC_CR_HSEON) ? 1UL : 0UL);

 

printf("HSERDY = %lu\r\n",

__HAL_RCC_GET_FLAG(RCC_FLAG_HSERDY));

 

printf("TCXO enabled = %lu\r\n",

LL_RCC_HSE_IsEnabledTcxo());

 

/*

* Wait for the 32 MHz TCXO clock to become ready.

*/

uint32_t startTick = HAL_GetTick();

 

while (__HAL_RCC_GET_FLAG(RCC_FLAG_HSERDY) == RESET)

{

if ((HAL_GetTick() - startTick) >= 100U)

{

printf("\r\nERROR: TCXO/HSE startup timeout\r\n");

 

printf("RCC->CR = 0x%08lX\r\n",

RCC->CR);

 

printf("HSEBYPPWR = %lu\r\n",

(RCC->CR & RCC_CR_HSEBYPPWR) ? 1UL : 0UL);

 

printf("HSEON = %lu\r\n",

(RCC->CR & RCC_CR_HSEON) ? 1UL : 0UL);

 

printf("TCXO enabled = %lu\r\n",

LL_RCC_HSE_IsEnabledTcxo());

 

printf("HSE ready = %lu\r\n",

__HAL_RCC_GET_FLAG(RCC_FLAG_HSERDY));

 

printf("PB0 = %d\r\n",

HAL_GPIO_ReadPin(GPIOB, GPIO_PIN_0));

 

printf("============================\r\n");

 

return HAL_ERROR;

}

}

 

/*

* We only reach here when HSERDY is actually set.

*/

printf("TCXO/HSE READY\r\n");

 

printf("\r\n===== TCXO RCC STATUS =====\r\n");

 

printf("RCC->CR = 0x%08lX\r\n",

RCC->CR);

 

printf("HSEBYPPWR = %lu\r\n",

(RCC->CR & RCC_CR_HSEBYPPWR) ? 1UL : 0UL);

 

printf("HSEON = %lu\r\n",

(RCC->CR & RCC_CR_HSEON) ? 1UL : 0UL);

 

printf("TCXO enabled = %lu\r\n",

LL_RCC_HSE_IsEnabledTcxo());

 

printf("HSE ready = %lu\r\n",

__HAL_RCC_GET_FLAG(RCC_FLAG_HSERDY));

 

printf("PB0 = %d\r\n",

HAL_GPIO_ReadPin(GPIOB, GPIO_PIN_0));

 

printf("============================\r\n");

 

/*

* Enable calibration for cut 1.1 and later.

*/

CalibrationParams_t calibParam;

calibParam.Value = 0x7F;

 

SUBGRF_Calibrate(calibParam);

}

else

{

/*

* External crystal configuration.

*/

SUBGRF_WriteRegister(

REG_XTA_TRIM,

XTAL_DEFAULT_CAP_VALUE

);

 

SUBGRF_WriteRegister(

REG_XTB_TRIM,

XTAL_DEFAULT_CAP_VALUE

);

}

 

/*

* WORKAROUND:

* Trim output voltage power_ldo to 3.3 V.

*/

SUBGRF_WriteRegister(REG_DRV_CTRL, 0x7 << 1);

 

/*

* Initialize RF switch.

*/

RBI_Init();

 

OperatingMode = MODE_STDBY_RC;

 

printf("===== SUBGRF INIT COMPLETE =====\r\n");

 

return HAL_OK;

}

Here the command SUBGRF_SetStandby(STDBY_RC); is throwing an HAL error because RFBUSYS and RFBUSYMS are both 1 during the initialization. I am not sure what is causing that to trigger the RFBUSY. 

[db16122]

The difference between STM32WL55CCUX and STM32WL55JC1 is different pin count as well as package type. Maybe you need to start with hardware checking. Does these 2 board share any difference schematics but same software flow? Custom board or EVK?

[dilipraj1709]

Hi db16122.,

 

The STM32WL55CCUx is a custom board that is designed, for the STM32WL55JC1, I used the WL-55 Nucleo board. From the data sheet, the HSEBYPPWR when enabled will exclusively make PB0 as VDDTCXO, and should supply the TCXO. I measured the voltage after ensuring the RCC→CR has HSEBYPPWR is enabled, and HSEON is triggered. But I did not see HSERDY. Also the RFBUSY never went to zero causing the HAL_ERROR

 

Thank you,

Dilip Raj 

[db16122]

Thanks for your feedback, since the board is different, any schematics is different about TCXO design as well as related layout about the TCXO? It is an external crystal for 32MHz.

 

[Filippo_Malleo]

Hi dilipraj1709,

to me it is strange that the very same software is working in the Nucleo and not in your custom board, at least for one point: the value of PB0 voltage. Before even thinking to the causes for the TCXO not to start, I am wondering how it is possible that PB0 voltage is stuck at 0 V in your custom board and not in the Nucleo. 

The software must initialize PB0 as an output pin. Otherwise, the STM32 Nucleo board cannot operate. Can this be confirmed?

Next, I would check if in the custom board there is some connection that is keeping the PB0 line stuck at 0V,

BR,
Filippo

[dilipraj1709]

Hi ​@Filippo_Malleo, 

 

In my custom board, when I make PB0 as an output GPIO, I am able to see 3.3V, but when I configure the PB0 as the VDDTCXO, I am not able to see the PB0 getting high. We used the WL55 Evaluation board and used the JC1 package as reference to design the STM32WL55CCUx board. 

[Filippo_Malleo]

Hi, dilipraj1709,

so, you configure PB0 in analog mode, enable VDDTCXO supply but you read 0 V instead of 3.3 V? If you remove the TXCO component from the board, you still get 0 V or 3.3 V?

[dilipraj1709]

Hi ​@Filippo_Malleo. 

 

I understand from the STM32WL55 document that PB0 can be configured as VDDTCXO or an Analog output pin.

When we configure the PB0 as VDD TCXO, it is directly controlled by the internal hardware step-down Switch-Mode Power Supply (SMPS) or low-dropout (LDO) radio sub-system controllers to scale and output a clean, programmable voltage range required by the external 32 MHz crystal oscillator.

My question here is since this is an internal process, when I currently configure the STM32WL55CCUx with PB0 as VDDTCXO, I am not seeing any supply from the PB0 pin. 
But when I configure PB0 as a Analog GPIO output, I am seeing the supply voltage of 3.3V