2025-05-15 4:14 AM
Hello everyone,
I have encountered an issue with the STM32WB05KZ on a custom board which only allows me to flash the board under very specific conditions. The first time out of the box, everything works fine, I can flash using a ST-LINK V3-PWR straight from CUBEIDE V1.18.0. After this first time programming, the board becomes fully unresponsive to the debugger. My code does seem to run (verified by two LEDs connected to PB4 and PB5). When using STM32CubeProgrammer, the system reports that it's unable to read the Chip ID. After much trial and error, I've found that by disconnecting the reset pin from the debugger and pressing the Close Debug button in the Debug Authentication (which I haven't enabled anywhere) menu, I can connect to the board through the STMCubeProgrammer software. I was wondering if this behaviour is to be expected, because I can't find it in the Reference manual or Datasheet. And if this behaviour can be disabled.
For context:
- The board has a 32 MHz crystal and a 32.786 KHz crystal. The issues presents itself even when they are not enabled in CubeMX.
- The PA3 and PA2 pins are not touched in any way after initialisation. I've tried this with a brand new project with no user code. I only switched the Serial Viewer option on.
- The Boot pin (PA10) is pulled to ground by another MCU, which I've confirmed to be working correctly with a multimeter.
- The reset pin is connected to ground with a 100nF capacitor
- The optionbytes (only RDP) is set to FF, meaning it should be accessible by a debugger.
- If I connect the board to STMCubeProgrammer, I can upload code directly.
They only thing I see that might be an issue is that STM32CubeProgrammer reports that the bootloader version is --. Does this mean that there is no bootloader?
Any help is greatly appreciated!
2025-05-15 4:18 AM
Open STM32CubeProgrammer, connect using HotPlug or under reset mode, and check:
Secure Area / DA status in "OB" tab.
Device security state — if it says “Secure” instead of “Open” you are locked out and DA is active.
If DA is active, you must go through the DA unlock workflow or mass erase to restore access.
Important: Even if you don’t explicitly enable DA, CubeMX or HAL code might unintentionally touch TrustZone-related registers.
2025-05-15 4:35 AM
Hello ahsrabrifat,
Thank you for your quick reply! If I switch to under reset mode or hotplug mode, I still can't connect to the MCU. I have to do the aforementioned method of pressing the close debug button. When I connect through this way, I can see the following in the option bytes section. Unfortunately, I don't see the device security state outside of the RDP option byte.
I do see that something in the register section is not zero, which is the vectkey.