NUCLEO-WL55JC1 Status 0xAA - Command Execution Failure

[RLind.3]

Hi there,

I am attempting to generate a simple FSK TX packet with the NUCLEO-WL55JC1 development kit, but I am struggling to understand how to enable the SUBGHZ radio and get it working. I have tried writing my own hardware interface with no luck, and when I have gone back to using the ST HAL I have gotten the same results. No matter what I try, I keep getting a status of 0xAA, which I believe means the radio is in Standby mode and has experienced a Command Execution Failure. The datasheet describes this as "Command successfully received but cannot be executed at this time, requested operating mode cannot be entered or requested data cannot be sent." This status doesn't change if I try and put the radio into another mode (for example FS or TX mode).

Does anyone have any ideas as to what could be wrong? I am assuming that I haven't initialised the radio correctly, but I haven't found a lot of initialisation guides. My initialisation code is below.

        // Reset radio
	RCC->CSR |= RCC_CSR_RFRST;
	HAL_Delay(5); // Must be held for at least 100us?
	RCC->CSR &= ~RCC_CSR_RFRST;
 
	// Make sure radio is out of reset
	while(RCC->CSR & RCC_CSR_RFRSTF);
 
        // Wait until startup completed
	HAL_Delay(5);
 
	// Pull NSS low for at least 20us
	subghz_cs_enable();
	volatile uint16 count = 0;
	for(volatile uint16 i = 0; i < 999; i++)
	{
		count = i;
	}
	subghz_cs_disable();
 
	// Wait for calibration
	HAL_Delay(5);
 
	// Set rf calibration between 882 and 902 MHz
	rf_calibrate_image(0xDC, 0xE2);
 
	// Make sure radio isn't busy
	while(PWR->SR2 & PWR_SR2_RFBUSYMS && PWR->SR2 & PWR_SR2_RFBUSYS);
 
	// Set location of data in FIFO to origin
	rf_set_buffer_base_addr(0x80, 0x00);
 
	// Set packet type to FSK
	rf_set_packet_type(0x00);
 
	// Set packet parameters
	rf_set_packet_params(360, 4, 16, 0, 0, 12, 1, 0);
 
	// Set sync word to 0x4DB3
	uint8 sync[] = {0xB3, 0x4D};
	rf_write_register(0x06C6, sync, 2);
 
	// Set RF frequency to 892MHz
	rf_set_rf_freq(0x37CE5E35);
 
	// Set PA config (values from datasheet)
	rf_set_pa_config(0x04, 0x00, 0x01);
 
	// Set TX parameters
	rf_set_tx_params(0x0E, 0x04); // Ramp time = 200us TODO change?
 
	// Set modulation parameters
	uint8 bit_rate[] = {0x06, 0x82, 0xAB}; // 2.4 kHz
	uint8 f_dev[] = {0x00, 0x0C, 0xCD}; // 3.125 kHz
	rf_set_mod_params(bit_rate, 0x08, 0x15, f_dev);
 
	// Enable TX/RX done, valid sync, and timeout IRQs on line 1
	rf_config_dio_irq(0x020B, 0x020B, 0x00, 0x00);
 
	// Unmask radio IRQ
	EXTI->IMR2 |= EXTI_IMR2_IM44;
 
	// Enable radio IRQ
	PWR->CR3 |= PWR_CR3_EWRFIRQ;

When I tried using the HAL, my initialisation code was:

  HAL_Init();
 
  /* Configure the system clock */
  SystemClock_Config();
 
  /* Initialize all configured peripherals */
  MX_GPIO_Init();
  HAL_SUBGHZ_Init(&hsubghz);
 
   uint8 status;
   HAL_SUBGHZ_ExecGetCmd(&hsubghz, RADIO_GET_STATUS, &status, 1);

I have a few questions about initialising the SUBGHZ radio:

1. Does the SMPS need to be running to transmit a packet? If so, is it enabled through the radio or the MCU? Both appear to have the ability to do so.
2. Is there a peripheral clock enable (or similar) for the radio in the same way there is for other peripherals?
3. What is the difference between RFBUSYS and RFBUSYMS? I didn't understand the explanation in the datasheet.

Note, I am trying to transmit using the LP PA at 14 dBm, using generic FSK, at 892 MHz.

Thanks,

Rebecca

[JKo]

1. No. I don't know the answer to the second part since I have not enabled it.
2. RCC_APB3ENR bit 0.
3. From what I could figure out from the documentation, the RFBUSYMS is supposed to cover the period between NSS going high (deselect subGHz radio SPI) and RFBUSYS (T_sw) going high. The internal state machine in the sub-GHz radio has a delay (T_sw) up to 600ns after NSS high before the RFBUSYS is valid. RFBUSYMS is supposed to go low after RFBUSYSMS delay or after RFBUSYS has gone low. I say "supposed to" because it doesn't do that. Instead the RFBUSYSMS stays high long after the command is completed. I suspect that the RFBUSYMS is latched to go high with NSS but only goes low if RFBUSYS also goes high before going low.

[RLind.3]

I managed to get the TX and RX functionality working. The two major issues I found were:

• Not enabling the TCXO - this was hidden in the HAL MSP code and I missed it.
• Not writing to the SPI_DR buffer EXACTLY as in the HAL code. I've used my own SPI code on other STM32's with no issues, but something seems to be different about this one. Writing to the SPI_DR as shown below allowed me to communicate reliably with the radio:

volatile uint8_t *spidr = ((volatile uint8_t *)&SUBGHZSPI->DR);
*spidr = data;

If you are struggling like I was, I would recommend going through the SUBGHZ_Tx_Mode example code (AN5409) with a fine tooth comb and making sure that you are doing every single step that they are.

[JKo]

Thanks. I also have TX and RX working with FSK long packets. I am not using the STM32CubeMX HAL.

I still do not have RFBUSYMS status check working as described in 6.3 radio busy management.

The RFBUSYMS is always high instead of changing to low at the end of "minimum RFBUSYMS delay" or when RFBUSY signal goes low. The CubeMX code ANDs (&) the RFBUSYMS and RFBUSYS to determine if radio is busy which isn't right if RFBUSYS may take t_sw (600ns) to go high after NSS goes high.

[RLind.3]

I have been doing it the way the CubeMX code does, and it has been working ok for me. However, I am also using a low clock speed (4MHz) so the potential 600ns delay is only a few clock cycles for me. It might be worth contacting ST directly for clarification?