Summary and problem description
The STM32WL55 is a dual-core, low-power microcontroller with a sub-GHz radio that is connected internally through SPI. Note that whenever "radio" is mentioned in this article, it relates to "sub-GHz radio".
To enhance security on the dual-core architecture, access to the radio can be disabled for one of the cores by setting an Option Byte (OB) bit. Typically, the CM4 core runs the application while the CM0+ core runs the radio stack. Disabling access from the CM4 core to the radio can improve security.
The STM32WLE5 is a single-core version of the STM32WL55 microcontroller that also has the same Option bytes. Therefore, the security feature that restricts access to the radio from the CM4 core can also be enabled on the STM32WLE5.
This FAQ article addresses issues, such as receiving a timeout when attempting to access the radio through the SubGHzSPI interface. This also includes reading out a value of '0x0' in all registers related to the SubGHzSPI.
Figure 1 - Timeout in the SubGHzSPI transmit function.
When the driver waits for TXE (Transmit Empty) to confirm that the SPI byte was sent, the registers may appear as all '0x0' values if the security feature is enabled. This causes the driver to timeout, as shown in Figure 1 above. Note that the '0x0' values can also appear if the peripheral is not enabled in RCC. This however usually leads to a Hardfault when attempting to access.
Figure 2 - SubGHzSPI registers when security is enabled.
There may be other symptoms that the SubGHzSPI is secured, but the two issues mentioned above are the most common. To verify that the security feature is enabled, CubeProgrammer can be used. With the STM32WL55, this can be seen directly in the "Option bytes" tab.
Figure 3 - STM32CubeProgrammer Option bytes view.
On the STM32WLE5, the option byte is hidden, so it can be viewed only directly from the memory. The reference manual RM0453 specifies the SUBGHZSPISD bit @0x1FFF7870
Figure 4 - RM0453 SUBGHZSPISD Option bit.
This address can be viewed in CubeProgrammer to check the settings of this bit. Option bytes have the concept that the value in one word is present in the next word as the negation of the value.
Figure 5 - SUBGHZSPISD - security enabled.
Figure 6 - SUBGHZSPISD security disabled.
1. Problem solution
The solution to this issue is simple - disable the sub-GHz radio SPI security by enabling the SUBGHZSPISD bit to allow access to the radio. With the STM32WL55, this can be done directly in CubeProgrammer through the Option bytes menu.
However, with the STM32WLE5, the bit is not visible in the Option bytes menu. It is necessary to write into both words at the same time due to the memory check with the negated value. The easiest way to enable the bit on both STM32WL55 and STM32WLE5 is to let the microcontroller do the programming.
To do this, the FLASH_WriteProtection example in the STM32CubeWL repository can be modified to disable the security. The example can be found in:
\STM32Cube_FW_WL_V1.3.0\Projects\NUCLEO-WL55JC\Examples\FLASH\FLASH_WriteProtection
The following code snippet can be used to accomplish this:
HAL_FLASH_Unlock();
__HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_OPTVERR);
HAL_FLASH_OB_Unlock();
OptionsBytesStruct.SUBGHZSPISecureAccess = OB_SUBGHZSPI_SECURE_ACCESS_DISABLE;
HAL_FLASHEx_OBGetConfig(&OptionsBytesStruct);
if(OptionsBytesStruct.SUBGHZSPISecureAccess != OB_SUBGHZSPI_SECURE_ACCESS_DISABLE){
//disable security of SubG SPI
OptionsBytesStruct.SUBGHZSPISecureAccess = OB_SUBGHZSPI_SECURE_ACCESS_DISABLE;
HAL_FLASHEx_OBProgram(&OptionsBytesStruct);
HAL_FLASH_OB_Launch();
HAL_FLASH_OB_Lock();
}
2. Root cause and further support options
The root cause of this problem is currently unknown. Based on the information gathered so far, the security disable bit may be spuriously unset on some STM32WLE5 devices, which is why this FAQ was created. One possibility is that the STM32CubeProgrammer modifies this bit under certain conditions when programming the option bytes. However, these conditions have not been reproducible on our side, so we are asking for your help.
If you are facing the issue described above, contact us through our support system and provide as much information as possible. The information presented in the bullet points below can help us identify the problem. For the time being, the proposed workaround should at least fix the problem described in this FAQ.
- What version of CubeProgrammer or CubeIDE was used with the affected device?
- How many devices out of how large a sample of devices are affected?
- Are the Option bytes programmed on your device or by CubeProgrammer?
- Is there a way to reproduce the issue, or to re-lock the device the same way once it has been fixed by the presented workaround?