STM32H735 - Error in initializing ST-Link device.Reason: (4) No device found on target.

[HSamm.1]

I'm getting above error both of the two STM32H735G discovery boards that I have. On both boards ST-Link worked fine for some time until I unplugged the ST-Link USB connection while the MCU was stopped at a breakpoint. Afterwards it seems impossible to get them back to live. As soon as connected it turns on backlight and shows a white display. The reset button seems to have no effect. It is hard to believe that both boards have a similar hardware failure all a sudden.

I'm out of ideas, can anybody help?

[Mike_ST]

Does your program configure PA13/PA14 ?

[HSamm.1]

Not knowingly. The ports are declared in the generated main.h as JTCK and JTMS, but there is no further reference to it elsewhere in the code.

[Mike_ST]

Maybe you can try a "connect under reset" with STM32CubeProgrammer.

Keep reset button pressed, click on the connect button on the GUI, then release reset, to see whether you have acces to the MCU.

[HSamm.1]

Tried this before, and now again waiting different times before releasing the reset button. Used the run button though, as I could find the connect. This is the first time I'm using the STM32CubeIDE, so I'm still trying to find my way around it. Used the SEGGER IDE in previous projects, but with this new board it wasn't possible to reflash ST-Link. Still things worked fine for a few days until I unplugged the ST-Link USB connection which is also powering the board at the moment.

[HSamm.1]

Nearly solved the problem. Reading 6.2.4. user manual of the discovery board, I learned that a mismatch of firmware vs. hardware MCU power source would cause a lockup between MCU and the ST-Link. Following the instructions, I was able to erase the entire flash memory using STM32CubeProgrammer while booting from the system ram. I must have set something in CubeMX when generating code that set the power config to LDO. (Need to see what caused that). Edited main.c to change back to: PWR_DIRECT_SMPS_SUPPLY. It loaded and verified code, but then lost connection to the MCU before even reaching the entry point. Any ideas what could still be wrong?

[HSamm.1]

Just had another go at it and now its back to working correctly. Not sure why the first attempts failed.

[thomfischer]

CubeMx 6.1.1 generates wrong code in SystemClock_Config().

I had the same problem and erased the board over USB FS with cubemx programmer.

(set JP7 5V PWR to USB FS and switch SW1 to SYS MEM)

/**

 * @brief System Clock Configuration

 * @retval None

 */

void SystemClock_Config(void)

{

 RCC_OscInitTypeDef RCC_OscInitStruct = {0};

 RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};

 RCC_PeriphCLKInitTypeDef PeriphClkInitStruct = {0};

 /** Supply configuration update enable

 */

// HAL_PWREx_ConfigSupply(PWR_LDO_SUPPLY);         // ! wrong

 /** Configure the main internal regulator output voltage

 */

 /*!< Supply configuration update enable */

   HAL_PWREx_ConfigSupply(PWR_DIRECT_SMPS_SUPPLY);  // ! default config, see schematic

 __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE0);

 while(!__HAL_PWR_GET_FLAG(PWR_FLAG_VOSRDY)) {}

 /** Configure LSE Drive Capability

 */

[HSamm.1]

Thanks, found that and found that CubeMX seems to be set by default to PWR_LDO_SUPPLY in the RCC settings. Once you load the generated code, it works until you cycle power. So it worked for me for two days, as I didn't unplug the board. Once I did it was hosed and I took the second board which also worked until I unplugged it. Crazy.

[thomfischer · Accepted solution]

use cubemx programmer,

can you connect to the board over STLINK and erase it ?

if not

can you connect to the board over USB (CN14 USB FS) and erase it ? (set JP7 5V PWR to USB FS and switch SW1 to SYS MEM and reset)

if erased you can try to program the attached hex file to test the board

(blinks green led (900ms on 100ms off) and does some output on stlink serial port 115000 8N1

with this hex file you should be able to repower the board without problems