The LED of the STLINK-V3 on NUCLEO-H755ZI-Q Board Keeps Red

[UOSTime]

Hello, I am a high school student and also a fan of STM32. I encountered the problem in the title, and the following texts are how things happened.

I bought this NUCLEO-144  board, and suddenly found the clock speed generated by the STLINK is too slow. So, I put a 24MHz crystal oscillator on the board, correctly soldered the crystal with its compatible load capacitors, and all the SBs are correctly mounted or removed according to the datasheet of this board.

After that, I used CubeMX to generate proper code lines that initialize the crystal, RCC and GPIO. The code just worked fine as intended, and I get a perfect 24MHz sinusoidal wave from the oscilloscope after putting the probe on the HSE pins of the chip.

But after I disconnected the power supply and reconnected it the second day, I found that the board is dead. The code I uploaded yesterday malfunctioned; LD4 on the board, which shows how the STLINK is working, is always red; I could detect the STLINK device from Windows Device Manager, STM32CubeIDE, and Keil μVision 5, but once I try to load any code to the board, the IDE will pop up a window noticing “Failed to start GDB Server” and the console said “No device found on target.”

I’ m confused. Then, I used another USB cable, but nothing changed; I tried to remove the crystal and replace those SBs to get the 8MHz clock from the STLINK again, but the problem is still even though the waveform from the STLINK normally. Also, I measured the supply voltages, regenerated the code, replaced the crystal, upgraded the firmware of the STLINK, and almost done everything I could came up with to remove potential issues. However, this problem remains while everything else looks fine.

Therefore, I heard someone said this situation is caused by broken firmware of the STLINK, or the STM32H755 just burn out. I never used the USB OTG port, LAN port, or overloading the supply voltages, and I want to ask if there is a way to recover. I could remove and solder a new STM32F723 chip for the STLINK, or flash a new firmware to it. I hope that the chips are not totally dead.

Thanks.

[Tesla DeLorean]

Might be what you have running on the core.

On the upper top quadrant of CN11 you should be able to find a BT0 and VDD pin pair. Solder a jumper connector there, and take one of the spare jumpers from the back of the board to short BT0 to VDD.

Remove the power/usb cable completely, repeating twice, and then try to connect with STM32 Cube Programmer. If it connects, Mass Erase the STM32H7, and remove the jumper.

Check code related to LDO / SMPS selection, VOS settings, and PLL settings. These being wrong can brick the core.

The ST-LINK/V3 should have been able to provide a couple of frequencies, the STM32H7 should also be able to get higher rates via the PLL.

Replacing the STM32F723 isn't an option as the firmware is locked, and not available to end users.

Double check the SB feeding the MCO clock from the ST-LINK to the H7. I know you said you did, but check continuity 

[UOSTime]

Thanks for your reply!

I tried the method you've mentioned, and now the compiler could correctly identify ST-LINK and download code. However, unforturnately, the STM32H755 still doesn't work, no matter I change the SBs to ST-LINK clock or external crystal. I tried to solder a new crystal, replace the load capacitors, and none of them work. No waveforms generated when I measure the PH0 and PH1 pin. I loaded the official example code, without modifying any RCC, GPIO or PWR relative settings, and the chip still keep silence(I put all jumpers and SBs in their defaut location finally). Maybe the chip is dead. So sad.

Are there any encrypted firmware inside the STM32H755 chip? If not, maybe I could buy a new one and solder it on to see if it works.

By the way, I uploaded the screenshot of clock configuration and pin configuration. I will be really appreciated if you could help me check the configurations to see if there are any mistakes that lead to the problem.

Again, thanks a lot, and hope you have a nice day!

[Pavel A.]

This LED indicates USB over-current on the ST-LINK side. Was it this way before you've "improved" the board? If not -   something became damaged after your intervention. Valuable experience & achievement unlocked!

@Tesla DeLorean yep you're right! LD4 (COM) red does not mean error by itself.

[Tesla DeLorean]

LD4 on this board is the bi-coloured connection / communication LED, LD6 to the right is the Over-Current LED

[Tesla DeLorean]

The MCU should run from the internal 64 MHz HSI, if you do nothing it should continue running, so not calling SystemClock_Config() is a test you can do. If that works then focus on how you set things up in SystemClock_Config() and how it manages failure paths. Check that HSE_VALUE define matches your external clock expectations, and that the PLL / VCO settings don't exceed limits.

I'd suggest instrumenting Error_Handler() and HardFault_Handler() so you can check if code goes there to die. Perhaps toggle some LEDs, or output diagnostics to a serial port.