Updated STM32CubeIDE, can't find device on target

[magene]

I upgraded STM32CubeIDE to version 1.14.1 today and can no longer connect with my target.  The process  of updating CubeIDE also updated my STLink-V3PWR debugger to V3PWR V4.J3.B1.P4.  Now, programs that downloaded and ran just fine yesterday won't download with the "Target no device found" error.  

The STMCubeMonitor-Power (version 1.2.1) software can take control, power on the target, get the temperature, reset my target board and can run the ULP Bench Test and report a ULPMark Score.  That leads me to believe STMCubeMonitor-Power can download and run a program and my target board is still working. I don't have any other target boards available to try right now.

STM32CubeProgrammer gives a "Error: No STM32 target found!" 

I'd appreciate any suggestions about how to fix this issue before I try rolling back the firmware on the debugger.

Here's the error I get in the CubeIDE Console window

STMicroelectronics ST-LINK GDB server. Version 7.5.0

Copyright (c) 2023, STMicroelectronics. All rights reserved.

 

Starting server with the following options:

Persistent Mode : Disabled

Logging Level : 1

Listen Port Number : 61234

Status Refresh Delay : 15s

Verbose Mode : Disabled

SWD Debug : Enabled

InitWhile : Enabled

 

Target no device found

 

Error in initializing ST-LINK device.

Reason: No device found on target.

Here's the error that pops up the CubeIDE "Problem Occurred" window

Error in final launch sequence:

Failed to execute MI command:
target remote localhost:61234

Error message from debugger back end:
localhost:61234: Connection timed out.
Failed to execute MI command:
target remote localhost:61234

Error message from debugger back end:
localhost:61234: Connection timed out.
localhost:61234: Connection timed out.

Thanks

[CMYL]

Hello @magene 

On which board are you working ?

On some ST discovery boards there is a switch that selects the boot mode, from user flash or System flash? can you check if you have one ?

On STM32H7B3I-DK board for example, the switch is SW1. The steps to do if you are getting the "No STM32 target found" error message:

1. Disconnect the board (remove USB STLink)
2. Move switch SW1 to position "SYS MEM aka 3.3V"
3. Power cycle the board.
4. Connect with STMCubeProgrammer and perform a "Full chip erase" on the Flash memory.
5. Disconnect the board again
6. Move the switch back to the "Flash" position"
7. Power cycle the board
8. You should now be able to connect with STM32CubeProgrammer.

Best Regards,

Younes

[marimuthu02111982]

same problem here but i am using bluepill stm32f103c8t6

[magene]

Hello Younes

Thanks for the quick response. I should have mentioned I'm working on a new board we designed using a STM32H7A3LI MCU.  Our board does have a jumper that does that same thing as SW1 on the H7B3I-DK board. Good news: I was able to complete steps 1, 2 and 3 and was able to connect with STMCubeProgrammer, which I was not able to do before.  However, when I click the "Full chip erase" button, I get a Error: Mass erase operation failed.  Please verify flash protection".  Section 4.5.1 in the RM0455 Reference Manual talks about FLASH configuration protection but it's a little complicated and I don't want to make anything worse.  Is there a setting or button in STMCubeProgrammer that will disable flash protection safely?

Thanks again for the help

[CMYL]

Hi @magene 

To be sure it flash protection, connect your board using CubeProgrammer and check the content of option bytes. 

Mainly the following RDP and WRP !!

 

best regards

[magene]

I think I figured it out.  I had to uncheck nWRP0 in the Write Protection section of the Option Bytes.  Then click the "Full Chip Erase" button, then check nWRP0 again.  Now it looks like I'm back to being able to download, program and debug programs again. 

For my information, can you tell what I did wrong?  How will I know in the future if I have to go through this full chip erase process?  Or is this just a more dramatic version of hitting the reset button when all else fails?

Many thanks again for the quick and effective answer.

[CMYL]

Great news !! 

I didn't catch your last post :beaming_face_with_smiling_eyes:

I need to investigate with a board to be able answer your question: (For my information, can you tell what I did wrong?  How will I know in the future if I have to go through this full chip erase process?  Or is this just a more dramatic version of hitting the reset button when all else fails?) 

next week i can practice it and let you know !! because what is strange for me that I can't find any nWRP0 OB mentioned in RM0455 !! we have the nWRP bits in other families but not in the STM32H7A3/7B3 and STM32H7B0 series !! 

Any way, next week I let you know.

 

Best regards

[magene]

I spoke too fast.  I was able to download and debug one program one time.  I reset the board and I'm back to square one, CubeIDE can't find the device.  I went back to your step by step and I can connect to my board with BOOT0 connected to 3.3V.  However, when I uncheck nWRP0, I get this: "Error: Option Byte Programming failed Or modified by application after OB-Launch". Is there a better way to force a "Full chip erase"?

[CMYL]

Hi @magene 

I will investigate on Monday with a board, i'm at home !!

 

Best regards,

Younes

[magene]

Thanks for working on this.  I'll be interested to see what you find out.  In the mean time, here are a few more hints.

I still can't just clear all the flash. Here's a screen shot of what happens. I've tried checking and unchecking the nWRPx boxes and CubeProgrammer just sets them back to their default setting: nWRP0, 1 and 2 are checked. nWRP3-34 are unchecked and nWRP35-63 are checked. .

At one point after fumbling around reinstalling software and trying to clear at least some of the flash with CubeProgrammer, I was able to build a new Blinky program, load it with CubeProgrammer and it ran. I wish I could tell you what I did to get this little bit to work but it was kind a random process.  Unfortunately, when I try to load the program that I've been working on, I get the errors at the bottom of these messages.  This program is much larger than the Blinky program I mentioned above, it's something like 360 kBytes if that matters.

C:\Users\gene\AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\bin\openocd.exe -c "gdb_port 54042" -c "telnet_port 54040" -f interface/stlink.cfg -f target/stm32h7x_dual_bank.cfg -c init -c "reset init" -c "echo VisualGDB_OpenOCD_Ready"
Open On-Chip Debugger 0.12.0 (2023-10-02) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
libusb1 09e75e98b4d9ea7909e8837b7a3f00dda4589dc3
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : clock speed 1800 kHz
Info : STLINK V4J2B1S0 (API v3) VID:PID 0483:3757
Info : Target voltage: 3.280879
Info : [stm32h7x.cpu0] Cortex-M7 r1p1 processor detected
Info : [stm32h7x.cpu0] target has 8 breakpoints, 4 watchpoints
Info : starting gdb server for stm32h7x.cpu0 on 54042
Info : Listening on port 54042 for gdb connections
[stm32h7x.cpu0] halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000930 msp: 0x20020000
Info : Unable to match requested speed 4000 kHz, using 3500 kHz
Info : Unable to match requested speed 4000 kHz, using 3500 kHz
VisualGDB_OpenOCD_Ready
Info : Listening on port 6666 for tcl connections
Info : Listening on port 54040 for telnet connections
Info : accepting 'gdb' connection on tcp/54042
Info : Device: STM32H7Ax/7Bx
Info : flash size probed value 2048k
Info : STM32H7 flash has dual banks
Info : Bank (0) size is 1024 kb, base address is 0x08000000
Info : Device: STM32H7Ax/7Bx
Info : flash size probed value 2048k
Info : STM32H7 flash has dual banks
Info : Bank (1) size is 1024 kb, base address is 0x08100000
Warn : Prefer GDB command "target extended-remote :54042" instead of "target remote :54042"
Info : Device: STM32H7Ax/7Bx
Info : flash size probed value 2048k
Info : STM32H7 flash has dual banks
Info : Bank (0) size is 1024 kb, base address is 0x08000000
Info : Device: STM32H7Ax/7Bx
Info : flash size probed value 2048k
Info : STM32H7 flash has dual banks
Info : Bank (1) size is 1024 kb, base address is 0x08100000
[stm32h7x.cpu0] halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000930 msp: 0x20020000
Info : Unable to match requested speed 4000 kHz, using 3500 kHz
Info : Unable to match requested speed 4000 kHz, using 3500 kHz
Info : Erasing FLASH: 0x08000000-0x0805c000...
Error: wait_flash_op_queue, WRPERR detected
Error: erase time-out or operation error sector 12
Error: failed erasing sectors 0 to 45
Error: flash_erase returned -4
Info : accepting 'telnet' connection on tcp/54040

FWIW, it does seem possible that my current issue has to do with not being able to write to certain parts of memory.  The Blinky program that does run is 4.8 kB, the larger program that doesn't run is 360 kB and another program I tried that doesn't run is 216 kB.

[magene]

I was finally able to clear all the flash on my MCU.  I had to connect BOOT0 to ground (not 3.3VDC).  This seems incorrect but it did work.  I've started and stopped the program, the IDE, the STLink-V3PWR several times and shut everything down and rebooted the computer a couple of times and I can still download, run and debug my main program.  So that's good.  Hopefully, it will last for a little longer this time.

Thanks again for all the help and if you can figure out why connecting BOOT0 to gnd allowed me to clear the flash, I'd be interested to know.

It would also be nice to know what the nWRPx check boxes are doing since I can't find a mention of them in the reference manual.

[CMYL]

Hello @magene 

Great news to know that you are able to connect your board and erase its flash. 

- For boot there are 2 parameters, boot0 pin (controlled by boot switch) + BOOT_ADD0 (by default user flash 0x800_0000) and BOOT_ADD1 (by default system flash 0x1FF0_0000).

-  Connecting BOOT0 to gnd is the same thing as putting the boot switch into userflash position. If not working with putting the boot switch, may be the the switch is damaged!! ,

- Choosing the system flash as boot (boot switch or Boot pin to VDD), means you are executing the embedded bootloader. No need in your use case as the bootloader is used to reprogram the flash memory using one of the serial interfaces (usart, i2c ....)

- By default all the nWRPx must be checked, means that there is no sector in the flash that is write protected. Do you changes these nWRPx option bytes ? If not, does you application have some code changing the nWRPx flash option bytes ?  if none among above did, means that there is an issue in the hardware !!! 

- One more possibility to answer, why nWRPx is set, bootloader in the system flash is setting WRPx  but I double checked it is not the case !!!

 

Best regards,

Younes

[Sandeep_Yadav]

STM32CubeProgrammer is programming but STM32CubeIDE cannot