SWD problem STM32WL33

[DirkH]

I have designed a custom board. I have connected SWCLK to PA3 and SWDIO to PA12. I found I can not connect. So I made a patch and connected SWDIO to PA2 which seems to be default after boot. Now I can connect to the board. However after downloading my software the board becomes unaccessible. The code is running fine on a NUCLEO-WL33CC1 board.

I can not access the board with CubeProgrammer either. It is like bricked.

I found one issue with LSE which I have connected to PB14 and PB15 instead of PB12 and PB13. So I changed my code disabled LSE and enabled LSI and tested this on a new board. Initially I can connect but as soon as I try to singlestep through the code contact is lost and after that the board is no longer accesable in CubeProgrammer either.

I am running out of boards if I can not find a way to unbrick them. ​@STTwo-32 

[mƎALLEm]

Hello,

Any STM32Wxxx (STM32 wireless products) related question need to be posted in STM32 MCUs Wireless forum board.

I’m moving it.

Good luck.

[DirkH]

Thank you! I am really devastated, Have been working with STM32 for more than 10 years and never had such problem.

[Imen.D]

Hello ​@DirkH ,

Check whether your firmware enters Deepstop mode. 

As states in the UM3418: In deepstop mode, SWD connections and connections to STM32Tools are unavailable on STM32WL33. To program a new binary, enter bootloader mode by inserting a jumper between pins 5‑7 of the ST morpho connector CN3 and resetting the board by pressing the reset button (B4).

 

 

[DirkH]

Hello Imen.D,

no the the software does not enter Deepstop mode. Not yet, I have to get there eventually. I am using a custom board. On the Nucleo-WL33CC1 board the software runs fine.

[DirkH]

Update:

Tried to put the board into bootloader mode and connect from CUbeProgrammer. I am getting strange results on both the two boards I have programmed and also on completely new boards. Here is the log:

10:34:20 : STM32CubeProgrammer API v2.23.0 | Windows-64Bits 
10:34:25 : RTS low
10:34:25 : DTR Low
10:34:25 : Serial Port COM5 is successfully opened.
10:34:25 : Port configuration: parity = even, baudrate = 57600, data-bit = 8,                     stop-bit = 1.0, flow-control = off
10:34:25 : Activating device: OK
10:34:25 : Board       : --
10:34:25 : Chip ID: 0x95 
10:34:25 : Error: GET command not acknowledged!
10:34:25 : Reemission of Get command
10:34:25 : BootLoader protocol version: 8.2
10:34:26 : Warning: Device is under Read Out Protection
10:34:27 : Timeout error occured while waiting for acknowledgement.
10:34:27 : Error: GETID command not acknowledged!
10:34:27 : Reemission of GetID command
10:34:28 : Timeout error occured while waiting for acknowledgement.
10:34:28 : Error: GETID command not acknowledged!
10:34:29 : Reemission of GetID command
10:34:31 : Timeout error occured while waiting for acknowledgement.
10:34:31 : Error: GETID command not acknowledged!
10:34:33 : Timeout error occured while waiting for acknowledgement.
10:34:33 : Error: GETID command not acknowledged!
10:34:33 : Reemission of GetID command
10:34:34 : Timeout error occured while waiting for acknowledgement.
10:34:34 : Error: GETID command not acknowledged!
10:34:34 : Reemission of GetID command
10:34:35 : Timeout error occured while waiting for acknowledgement.
10:34:35 : Error: GETID command not acknowledged!
10:34:36 : Disconnected from device.

I attach the schematic as well. As said before I have shorted TP3 and TP1 in order to connect SWDIO to PA2. Basically connecting it to both PA2 and PA12.

[DirkH]

It turned out that the default setting when selecting UART in CubeProgrammer is wrong! Parity needs to be set to NONE for STM32WL33.

Now I could use the bootloader to erase the FLASH. ST-Link connects again and after some further adjustments of the cpu initialisation I am up and doing some productive work again.

Takeaway:

Never configure SWCLK and SWDIO to anything else than PA2/PA3 even though it is possible in CubeMX and according to the datasheet.

When using the bootloader set parity to NONE.

[Andrew Neil]

Never configure SWCLK and SWDIO to anything else than PA2/PA3 

Never say, “never” !

There are legitimate reasons for reconfiguring those pins to other than SWD - probably the commonest is to minimise power consumption in low-power modes.

But, of course, doing this means that you can no longer use SWD - so you cannot connect via ST-Link (or any other SWD probe).

There are ways to get around this; eg,

• Connect under Reset - the reset causes the pins to revert to their default SWD functions
• Have a delay from power-up before reconfiguring the pins - to give time to connect
• Provide some other trigger to “release” the pins.