P-NucleoWB55 ST-LINK error won't recognize

[kcire L.]

Hello,

I am having a problem with my P-NucleoWB55 development board. When using STMCUBEIDE and trying to debug, I get the following error.

Failed to start GDB server

Error in initializing ST-LINK device.

Reason: (4) No device found on target.

I also cannot connect using the STM32Cube Programmer.

Any ideas what could be happening? It was working with STM32Cube Programmer before I tried it with Cube IDE...

Thanks for any help.

[TDK]

What does your firmware do? Might happen if your firmware reconfigures SWD pins or goes into low power modes.

Trying connecting under reset in STM32CubeProgrammer. Does it detect a target voltage?

[kcire L.]

I was trying an example program using the STM32CubeIDE for the heart rate monitor.... CubeProgrammer detects a voltage and the STLink S/N so I think St link is working properly. Just can't connect to the target. There is target voltage recognized. Is there anyway to wipe the chip? I feel like it's locked some how.

Thanks for the reply

[Imen.D]

Hello @kcire L.​ ,

Make sure to upgrade the ST-LINK/V2-1 firmware and you correctly configured the jumpers.

Check your pins assignment following the Table 11. IO assignment in the UM2435 User manual for STM32WB Nucleo pack.

Make sure to use the latest CubeProgrammer tool.

Otherwise, can you download the option bytes?

If your issue is not resolved, please share a log when you tried to flash the board.

When your question is answered, please close this topic by choosing Select as Best.

Imen

[kcire L.]

Thanks for the reply.

What do you mean when you say download the option bytes? I tried to flash the hex file using cube programmer, but it says "No target found".

How can I share the log file when trying to flash the board? Where is that located?

Thanks again

[Imen.D]

I mean the log obtained by STM32CubeProgrammer, when using CLI command.

Have a look at the attached document, it maybe helpful regarding the configuration.

I think you should check in the device management if there is no problem with the ports, and try to disconnect the port in device management and reconnect.

Check if all jumpers are correctly configured :

• set correctly the jumper JP1 ([7-8] on USB STL).
• JP2 is ON
• JP3 is ON 

Imen

[kcire L.]

In order to flash the correct flash binary do I need to connect via USB-DFU bootloader mode?

If so, I did try this by changing my jumpers and connecting to the USB user connector. Then tried connecting with the CubeProgrammer under USB tab but says No DFU detected....

[HYu.4]

I have the exact same problem. And I am a fairly experienced STM32 user. Yes, JP2 and JP3 are on. Yes, JP1 [7-8] on. Yes, the red LEDs are on. Yes, the latest driver, and I can see it properly in my Window's device manager. Yes, the lastest CubeProgrammer version. I was also trying to load the Heart Rate example.

But it keeps giving me the following error message.

09:27:23 : ST-LINK error (DEV_CONNECT_ERR)

 09:27:34 : ST-LINK SN : 066BFF303430484257144137

 09:27:34 : ST-LINK FW : V2J39M27

 09:27:34 : Board    : P-NUCLEO-WB55

 09:27:34 : Voltage   : 3.25V

 09:27:34 : Error: No STM32 target found!

After a few extra hours of trial&error, I finally made some improvement. Yes, it is the heart rate example that screws it up. Once you program this app, you can no longer connect to target with ST-link. Instead, you have to use the USB-DFU bootloader mode as described in the ppt. So, never load this example again. Instead, I found the HeartRateFreeRTOS_ANCS example works just fine. You can view the heart beat on your phone and you can repeatedly load the program.

I still think the discovery kit is defective. Assuming most people who use the kit are new to the STM32WB series. How could you design something so cumbersome if your purpose is for people to learn? If the user is not a persistent person like myself, he could easily give up and just use a TI chip instead. Overall, I am disappointed at this kit.

[Tesla DeLorean]

If the STM32WB is non-responsive then yes going to be a challenge to communicate with it.

Your options are generally with "connect under reset", or with BOOT0=HIGH. If the chip goes into low power modes it turns off the pins and logic the debugger would use, there is a very narrow window within which the debugger needs to wrestle control. There are also option byte settings that can also preclude connectivity. Other thing include reconfiguring the pins, or explicitly disabling debug connectivity.

ST has a low presence here, most support is done with engineers on a business-to-business level based on the volume of orders and value of the customer.

>>I am convinced there is a defect in this discovery board.

In the sense that it's Ford's fault if you drive your car into the canal/duck-pond..

[HYu.4]

Thanks for the insight. I am new to the ST community although I am fairly experienced with the MCUs.

I have to respectfully disagree with you last comment, if I drive a Ford with their own example software/settings, and if all in a sudden, the car stops responding, I don't think it's the driver's fault! Here both Kcire and I were using the factory provided "hear rate" example as is. So there is definitely a defect in the example and/or the hardware.