ST-link loses connection with my STM32F769I discovery board

[bsayl]

Using STM32CubeProgrammer to connect to my discovery board. Connection to the board via ST-Link is lost within 30 seconds every time.

things I have done:

1.) Performed "full chip erase" via the STM32CubeProgrammer application

2.) Selected the appropriate external loader for my discovery board

3.) Tried to program the included demo file (STM32769I-DISCO_DEMO_V1.0.0_FULL.hex) but it never completes before the board disconnects

4.) Tried every combination of the "mode" and "reset mode" selections offered in the application

5.) Searched the forums for an answer and posted a support ticket to ST.... no response

Does anyone have any suggestions of next steps to try??

[waclawek.jan]

Try to use the STLink Utility instead of the CubeProgrammer.

Try a different USB port, different cable, different computer.

JW

[bsayl]

Hi waclawek thanks for your reply. Unfortunately the problem persists with multiple cables and multiple ports.

Just tried with the STLink Utility as recommended and lost connection again with the message

"22:59:21 : Connection to device is lost: check power supply and debug connection.

22:59:21 : If the target is in low power mode, please enable "Debug in Low Power mode" option from Target->settings menu."

[bsayl]

The device is being powered via the ST-Link connector with the on-board jumpers set for this option. I have previously tried using an external 5V supply (after switching jumper settings for this option) but the results are the same

[Tesla DeLorean]

What firmware version of ST-LINK firmware is being used?

Disconnection can occur if the device goes into power down mode, or browns out.

[bsayl]

ST-Link f/w version is : V2.J32.M22. Which was successfully updated from the Utility program.

I had a multimeter on the 3.3V and 5V supplies yesterday and they showed no deviation when the disconnect event occurs.

Incidentally I just tried loading a simple blinky script from the MBED on-line compiler and that seems to work (led is blinking) but the connection problem through the utility application persists.

[Andreas Bolsch]

Check option settings for both watchdogs, if one is activated automatically, it will certainly kick in.

Had this once with an older STM32F746g-Disco, not with STM32F769i-Disco, but ...

[bsayl]

Hello Andreas,

The STM32 world is new to me. So I'm doing my best to find the watchdog settings you mentioned above. I made my way to "Option Bytes" using the ST-Link Utility application and have attached an image of what I'm seeing.

I really have no clue as to whether these are correct or not per your post above. I will do some reading up on what each of these options means... in the meantime could you offer an opinion as to whether these settings might be posing a problem?

Very thankful for all the help thus far

Brad

[Andreas Bolsch]

It *looks* like both watchdogs are not activated automatically --- if a checked checkbox means bit set to '1'. Regarding the ST-Link Utility I had an unpleasent experience with a H743 where the sense was apparently inverted, hence I woudn't rely on that. So to be really sure, I'd inspect location 0x1FFF0000, it should contain 0x5500AAFF, the factory default.

BTW Did you check the NRST pin? An internal (watchdog) reset should be visible there. Only a few us, though. And after an unsuccessful programming attempt, did you inspect the memory, i. e. was the internal flash programmed completely or only partially? Same for the external flash.

And did you measure the time from start of programming to failure? Always precisely the same or grossly varying?

[bsayl]

Hi Andreas,

Thanks for sticking with me on this. To answer your questions:

1.) Yes address 0x1FFF0000 contains 0x5500AAFF

2.) I scoped the reset line. I am, in fact, getting a 3V3 to 0V transition lasting ~4ms on every disconnect. I have attached a capture of the plot. It falls, then tries to come back up after ~1ms, falls again and finally goes high again after ~4ms.

3.) I paged through the memory readout and found only 0xFFFFFFFF, both in the internal flash (starting at 0x08000000) and external flash (starting at 0x90000000)

4.) Time to reset after connecting varies from ~2s to ~20s (measured 30 times). The spread looks to be evenly distributed.

Do these fact suggest anything in particular to you?

all the best,

Brad

[Andreas Bolsch]

I'm afraid that looks like hardware defect to me. You've ruled out cables, power supply and you can program the internal flash successfully (for the blinky), so the external flash is causing trouble, I guess. The reset pulses can hardly be internally caused as the watchdogs are neither activated automatically nor by firmware, so probably by the STLink.

Very littel hope, I suppose. You could try to program the whole internal flash with random data and read back this to verify that all sectors are ok, just to confirm it's not the internal flash. Write protection is not likely either, as STLink Utilily would certainly detect this at the very beginning.

With the external flash: Check that signals on all 4 data lines and CLK, CS are clean rail-to-rail, as far as I recall it the pads are well accessible for a scope. If no problem there, the last resort I can think of is openocd with the patch http://openocd.zylin.com/#/c/4321/. Activating full debug might give a clue, and it's possible to check and modify all configuration registers of the flash chip. But this will need considerable amount of work and time ...