STLINK Problems with STM32H745i-DISCO

[maxpartenfelder]

Hi,

I just got my H745i-DISCO board and started to tinker with ToughGFX right away. I got a test application loaded on the board, but once I disconnected the USB connection and reconnect it (USB connected to STLink USB Port on Nucleo board, power jumper in first position) the STLINK seems not to recognize the MCU anymore. The loaded flash drive contains a "FAIL.txt" file with the following content: "The interface firmware FAILED to reset/halt the target MCU".

When I press and hold the reset button while plugging the USB and releasing it within 2 seconds, the FAIL.txt is not present. Either way, I can't get TouchGFX or STLink Utility to connect to the MCU. I tried all day and only got it to again recognize the MCU once. Then I did a full chip erase with STLink Utility and loaded another application with TouchGFX. Unplugging the USB, plugging it again, same error.

What am I doing wrong? How can I get consistent results?

What I've tried so far:

• Supplying the board via the scond USB power conn while keeping the STLink port connected
• Dis- and reconnecting the 3.3V MCU power jumper JP1
• Updating the onboard STLink to the latest firmware
• Doing the "connect under reset" option as suggested by STLink Utility
• Restart my computer

Any advice is warmly welcome

Best regards

Max

[Tesla DeLorean]

Going to have a lot of sensitivity to LDO/SMPS and VOS code in ConfigSystemClock()

Strap BOOT0 High, cycle the power a couple of times, then try to connect.

[maxpartenfelder]

Thanks for the answer.

Unfortunately this didn't work for me. I still can't connect to the MCU.

[hansd56]

Try this

RCC_OscInitTypeDef RCC_OscInitStruct = {0};

 RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};

 RCC_PeriphCLKInitTypeDef PeriphClkInitStruct = {0};

 /** Supply configuration update enable

 */

 HAL_PWREx_ConfigSupply(PWR_DIRECT_SMPS_SUPPLY );

 /** Configure the main internal regulator output voltage

 */

 __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);

 while(!__HAL_PWR_GET_FLAG(PWR_FLAG_VOSRDY)) {}

The zipped project is just some experimentation with the STM32H745i-DISCO board. It should compile with System Workbench with dual core debugging.

I always had success connecting to the board again after it bricked up with deleting all flash. I think I used the external STLink-V3SET for it. Might be a good idea to get one.

[maxpartenfelder]

Thanks for your answer and the demo project.

So far, I only tried to flash some sample applications with the TouchGFX Designer. There I selected the H750 Discovery board since the H745 is not listed there. Maybe this lead to the unresponsiveness of the board.

Just for my understanding: why does it make a difference programming the discovery board with an external STLink compared to the built-in one? And is it also possible to use an STLink-V2 (which I have lying around, still no connection possible) or is it not compatible with the H745?

[Tesla DeLorean]

The V2 didn't understand dual cores, the firmware may have caught up by now. If the on board ST-LINK won't connect, and external one won't either.

I did this with one of the first H747 DISCO boards.

The prescribed method to unbrick is to boot/restart into the System Loader ROM a couple of times (Power Cycle with BOOT0=High), and when you get access to then Mass Erase the device. You might need to repeat several times, I had to solder a wire on BOOT0. Power the device from one USB cable to the ST-LINK, and remove it for several seconds before reinserting.

If this still doesn't work, you'll need to discuss options with an ST FAE

[TJung]

Hi,

i have the same problem with the Nucleo-H745. I still waiting for an answere from an Rutronik FAE.

The H745 seems to be very sensitive.

I am working many years with Nucelo boards of several times an i have running a nice product based on the H743 which is much less sensitive.

Thomas

[Tesla DeLorean]

I had an early H747I-DISCO with the X stepping, felt pretty stupid as the first code ported from the H743 immediately bricked the device, and it was entirely life less.

The access to the BOOT0 ball was unhelpfully via a 0402 or 0201 resister pad, so it was impossible to hold tweezers on it while juggling power cords and reset buttons. Kept reconnecting it until the ST-LINK could access the device. I left the wire soldered to the board, and redirected execution to the FLASH code in Keil's debugger from then on out. I did recommend to ST they put an actual jumper on the pin, because they were going to need it.

First couple of lines in SystemClock_Config() need to be correct for the chip/board otherwise it is Game Over.

[TJung]

Hi,

i had some success with the BOOT mode method.

• Connect the BOOT0 pin to 3,3V.
• Power on the board
• Remove the 3,3V from the BOOT pin (but do not power off the board)
• Reset the chip by using the reset pin (black button on the Nucleo Board)

This works for me several times now, but it can still not be a solution to do this hack every time you power down the board :(

On the Nucleo schematic you will find several power options. The default is to use the SMPS. Would it solve the problem using the LDO?

For me it doesn´t matter if i need a bit more current.

Thomas

[maxpartenfelder]

Thank you for the instructions Thomas,

I will try it later.

What I don't understand is the source of the problem in the first place.

Above, it's stated that the SystemClock_Config has to be correct, You pointed out that the power supply might be a problem.

But just for my understanding: what exactly is the current state of the board / processor and why is it not executing the program stored in the flash properly?

Thanks again

Max

[Tesla DeLorean]

My understanding is that they have a persistent setting, and it always starts thru the ROM, perpetuating the setting. The BOOT0 pin changes how code execution forks into FLASH code.

[TJung]

Hi Max,

don´t ask me that.

I bought a new Nucleo to test the dual core. I connected the new board and it works as long as i did not disconnect it from power (USB). The next day i tried again and nothing works. I thought ok my fault and ordered new boards. The same story.

Using the code from above does not work for me. It stucks in the while loop.

But there are more inconsistencies:

Here is the generated code from CubeMX:

RCC_OscInitTypeDef RCC_OscInitStruct = {0};

 RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};

 RCC_PeriphCLKInitTypeDef PeriphClkInitStruct = {0};

 /** Supply configuration update enable 

 */

 HAL_PWREx_ConfigSupply(PWR_LDO_SUPPLY);

 /** Configure the main internal regulator output voltage 

 */

 __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE3);

 while(!__HAL_PWR_GET_FLAG(PWR_FLAG_VOSRDY)) {}

 /** Macro to configure the PLL clock source 

 */

It seems that the code configures the LDO, but on the Nucleo board the SMPS is used.

But it works (at least with the hack).

Thomas

[maxpartenfelder]

I still have a Support Ticket running for this issue. I will post some updates if ST decides to answer it.

[hansd56]

Hi,

Whilst I was testing something for maxpartenfelder problem the board was bricked too. I found out that voltage regulator U20 did not produce 3.3V. To verfy I feed in 3.3V on TP20. I was able to load firmware again. The STM32H745i-DISCO went into the bin and back to iMX RT1052. What a shame.

[Linas L]

Also you can add big one second delay (like delay (0xFFFFFF) that just while with asm("nop") )

(note, this is not Hall function based on systic, but on nop operation so no coding for systic needed)

It will give you to press connect after manual restet. It works for me, but i have to not forget to add this code. Before any of your code is run on MCU, it will give STLink time to connect to CPU)

But that mean that boot is delayed by 1s. Maybe some one needs to get up and running faster.

[Tesla DeLorean]

It certainly would provide some margin to allow the debugger to wrestle control.

I'd probably use DWT CYCCNT, I'd suspect several hundred thousand cycles would suffice rather than 64 million.

Checking a GPIO, USART or button can also provide an escape route.

[Linas L]

My variant will run on any MCU family, so it could be written in seconds with no knoledge about MCU. and where is no penalty of flash memory, power consumption or register setting after this delay is over.

[TJung]

Hi,

on the NUCLEO-H745 the SMPS is used (the default config of the board is SMPS. see schematic of the NUCLEO-H745).

The root problem is that you use the LDO " HAL_PWREx_ConfigSupply(PWR_LDO_SUPPLY);".

Unfortunately this is the Code that the CubeMX generates.

Change this to: HAL_PWREx_ConfigSupply(PWR_DIRECT_SMPS_SUPPLY);

Make sure that you don´t use Voltage_Scale_0 and do not configure the CPU Clock higher than 400Mhz.

When this is fixed, first start the CM4 and than the CM7, because the CM7 times out and calls the Error Handler when the CM4 does not go to power down.

Best Regards

Thomas

[MMatu]

Hi

Actually, the PWR_DIRECT_SMPS_SUPPLY and PWR_REGULATOR_VOLTAGE_SCALE1 are used in H745 Cube package, GPIO example. As I wrote, this leads to the same problem. However I wasn't aware of cores starting sequence and run both of them simultaneously. I will try with that first CM4, second CM7 approach.