STM32WB55 custom board - Unable to connect to STM32CubeProgrammer

[ShenChuanAn]

Hello everyone,

I am working with a custom board based on STM32WB55CGU6. The MCU is brand new and no firmware has ever been programmed into the device.

The reset circuit and BOOT0 circuit are shown in Figure 1.

Problem:

I cannot connect to the MCU using STM32CubeProgrammer through SWD.

Connection settings:

Port: SWD
Mode: Under Reset
Reset Mode: Hardware Reset
Frequency: 4 MHz (also tested with lower frequencies)
STM32CubeProgrammer reports:

"No STM32 target found"

and sometimes:

"Unable to get core ID"

A screenshot of the error is shown in Figure 2.

Troubleshooting already performed:

Verified continuity of the SWD signals:
PA13 (SWDIO) to ST-LINK SWDIO
PA14 (SWCLK) to ST-LINK SWCLK
Power supply appears normal:
Target voltage reported by STM32CubeProgrammer is approximately 3.25 V
Power rails have been checked
Measured voltage:
Voltage measured directly between SWCLK and SWDIO is approximately 3.267 V
BOOT0 is pulled down to GND through a 10 kΩ resistor.
NRST is pulled up to 3.3 V through a 10 kΩ resistor and connected to the ST-LINK reset pin.
SWDIO and SWCLK each measure approximately 11.2 MΩ to GND, indicating no obvious short circuit.
STM32CubeProgrammer was tested using Under Reset mode.
Questions:

Is there anything specific to STM32WB55 that could prevent the debugger from reading the Core ID?
Are there any mandatory power pins, such as VDDA, VDDRF, VDDSMPS, or VBAT, that could cause this behavior if improperly connected?
Has anyone encountered a similar issue on a brand-new STM32WB55 device?
Any suggestions would be greatly appreciated.

Thank you.

Figure 1: Schematic of NRST and BOOT0 circuits

Figure 2: STM32CubeProgrammer error screenshot

[Ozone]

Related to this ?

https://community.st.com/t5/stm32-mcus-products/stm32u5g7vjt6-st-link-quot-target-no-device-found-quot-despite/td-p/901189

Anyway, the recommendations seems to apply here as well.

In the schematics, there is no VTRef output on the debug connector.

[ShenChuanAn]

Yes, the issue is very similar to the one discussed in that thread.

I reviewed the suggestions in the comments and tried the recommended troubleshooting steps, but unfortunately none of them resolved the problem.

Regarding VTRef，I used an FPC breakout connection to route the target VDD to the ST-LINK VTRef pin. The measured VTRef voltage is approximately 3.28 V, so the debugger is correctly sensing the target voltage.

I have also verified that the ST-LINK itself is working properly. The same ST-LINK can successfully connect to and program several of my other custom STM32 boards without any issues.

At this point, I am struggling to identify where the problem is occurring. The target board has a stable 3.3 V supply, BOOT0 is permanently pulled low on my hardware design and has remained low during all of my tests, and I have already tried Normal, Under Reset, and Hot Plug connection modes in STM32CubeProgrammer.

This MCU has never been successfully programmed or debugged since assembly.

Any further suggestions would be greatly appreciated.

[Ozone]

I'm not a hardware guy, but I know of a few circumstances which could cause this.

First, the circuitry on the rest pin (/NRST) is not correct, and/or the power is not up quickly enough. If the core is released from rest while the suply is not stable, it usually hangs in an undefined state.

> ... and I have already tried Normal, Under Reset, ...

The "Under Reset" requires a reset output from the debug pod, and a corresponding JTAG input. According to the schematics, your board does not have that.
You can try to short NRST manually after switching on, and try to connect via SWD afterwards.

Second, the MCU is on the ROM/System bootloader, regularly polling the defined input channels.
I would recommend to check the voltage level on the BOOT0 pin after supply turned on, to verify the state.

Third, RDP is enabled, and thus debugging access disabled. Which is unlikely, I would say.

You could pull BOOT0 high and try to get into the system bootloader, just to see if the MCU is alive.
Not sure if you have routed out any of the supported interfaces (UARTs are the easiest), the schematic doesn't reveal it. The Cube Programmer would come into handy here.

[ShenChuanAn]

The MCU I am using is STM32WB55CGU6.

On my custom board, I routed USART1 out on PB6 and PB7, because according to the datasheet alternate-function table, PB6 can be used as USART1_TX and PB7 can be used as USART1_RX.

However, when I try to connect through UART using STM32CubeProgrammer, I still get the error shown in Figure 1:

“Activating device: KO. Please, verify the boot mode configuration and check the serial port configuration. Reset your device then try again.”

After checking the datasheet again, I noticed that PA9 and PA10 can also be used as USART1 pins. Could this be the reason for the UART bootloader connection failure? In other words, does the STM32WB55 system ROM bootloader only support USART1 on PA9/PA10, even though PB6/PB7 are valid USART1 alternate-function pins for user firmware?

I also measured the NRST pin. Under normal conditions, NRST is about 3.28 V. When I press the reset button, it goes to 0 V, so the reset button itself seems to work.

Regarding BOOT0, it is connected to GND through a 10 kΩ pull-down resistor. I measured the BOOT0 voltage after power-up and it is 0 V.

This MCU has never been successfully programmed or debugged since assembly.herefore, I am not sure RDP be enabled,

[Ozone]

> After checking the datasheet again, I noticed that PA9 and PA10 can also be used as USART1 pins. Could this be the reason for the UART bootloader connection failure? In other words, does the STM32WB55 system ROM bootloader only support USART1 on PA9/PA10, even though PB6/PB7 are valid USART1 alternate-function pins for user firmware?

Unfortunately I lack the specific knowledge of the WB55 device(s), but the set of peripherals supported by the system bootloader is usually decumented in the datasheet. Here a screenshot from a F303 I worked with :

My idea behind trying to get into the system BL was to see if the MCU is ok, and the board is fine so far.
Perhaps you have a commercial board (like a Nucleo) with the same MCU or another PCB to try your setup.

Getting a custom PCB to work can be a pain, that is for sure., you can't take anything for granted.
In case the boards are populated in-house, I would try to get hold of a bare PCB, and check it with an ohm meter (continuity tester).

As said, I'm no hardware guy, and as such I can't judge the RF stuff in the schematics either.
Perhaps you can manage to populate just the bare minimum (power supply, UART / SWD interfaces), and check with such a board.

This MCU has never been successfully programmed or debugged since assembly.herefore, I am not sure RDP be enabled,

In your case (a factory-fresh MCU), RDP is implausible. 
But RDP would have the same effect.