STM32F746 "forgets" flashed program (and more)

[Lars Beiderbecke]

I migrated to a new self-created PCB with a STM32F746IE. I noticed that if I flash anything, the program works immediately after flashing, but not after power off/on. As a simple example, I created a program with two blinking LEDs. They blink after flashing, but remain dark after power cycling.

In both CubeMX and TrueSTUDIO, I selected STM32F746IE as device. I configured to use the TCM interface with ART controller and command prefetch. The flash for TCM interface is located at 0x0020 0000. Looking at the HEX file, I see that the target address is indeed 0x0020 0000.

For reference, here is my linker file: [removed]

I also cannot debug. Flashing works, the breakpoint at main() is created, but never reached. This is my debug script: [removed]

The power supply provides stable 3.3V and 1.2A. I disabled HSE and LSE and enabled HSI/LSI to rule out clock problems.

So what could cause the flash (and the debug) problems? Obviously, the layout or the soldering could be bad. But I solder SMD regularly, and I cannot find any lack of solder or shorts. The layout is more or less unchanged from the previous version with a STM32F722, which didn't have such problems.

Is there a way to further diagnose this? Since debugging doesn't work reliably, the memory view also doesn't work.

[MM..1]

When you power off on need Vcc have proper rising edge speed. On some speed MCU without reset dont start.

Try when your board dont blink use reset pulse without power disconnect

Second source of possible trouble i see in line

1. FLASH (xr) : ORIGIN = 0x00200000, LENGTH = 512K /* TCM bus, max=1024K */

from where you have this file?

Third is proper state on BOOT pins.

[Lars Beiderbecke]

I thought you nailed it with your second remark, as the FLASH line missed w -- however, adding it and building from scratch didn't change a thing. Also, when the linker file is generated by CubeMX, FLASH only has rx.

I'll test/check your other items now.

[MM..1]

rx is ok but ORIGIN is question , check datasheet about location of flash memory map

[Lars Beiderbecke]

Oh, I see. Yes, Flash on the TCM bus starts at 0x0020 0000:

[MM..1]

Yes but read too page about boot modes, you need program option bytes BOOT_ADDR for start from TCM

Normal default boot is i mean 0X0800 0000

[Andreas Bolsch]

In fact, the flash is aliased on 0x00200000, but the RM says explicitly

"64-bits ITCM interface:

– It is connected to the ITCM bus of Cortex-M7 and used for instruction execution

and data read access.

– Write accesses are not supported on ITCM interface <--- !!!

– Supports a unified 64 cache lines of 256 bits (ART accelerator)"

That is, for programming the flash, you must specify the address range starting at 0x08000000 (as for all STM32 devices). Depending on the programmer/software you're using, the address range starting at 0x00200000 might not be recognized as belonging to flash at all.

[Andreas Bolsch]

And depending on your programmer, there *might* be an option to use the ITCM-interface addresses for programming, see AN4667.

[Lars Beiderbecke]

Sorry, I shouldn't have panicked, but checked my layout instead.

[waclawek.jan]

You should also read the answers. It's in the very first one.

JW

[Lars Beiderbecke]

(nevermind)

[MM..1]

Maybe your MCU have POR level config or try set options for hw watchdog, but this is workarounds. First as i write on start, test RESET pulse, when this start your app you have this issue with Vcc, then on scope measure time on rising edge...

[waclawek.jan]

Try the program on a "known good" board such as Nucleo or Disco.

On your board, physically check every VDD and GND pin for good connection, including VDDA/VREF and any analog ground.

Try to strip the program down to the bare minimum, i.e. *no* call to clock setup routines, only port setup and the blinky.

Check in AN2606 the boot entry procedure. Aren't there any leftover flags set, which would act similarly to the BOOT pin? Or enable hardware watchdog?

As MM..1 said above, experiment with the hardware reset (NRST).

JW

[Lars Beiderbecke]

I wanted to test the RESET thing, when I discovered the actual cause of the problems: When I disconnect the J-Link programmer, everything works. If the J-Link programmer is connected, the STM32 doesn't start. If I remove the NRST wire of the connected programmer, then the STM32 also starts up.

I'm using SWO without trace, and the J-Link connector is this 5-pin connector:

I doublechecked that the J-Link programmer is connected correctly to this connector, and of course I'm able to flash with this. The above pin is connected to NRST, which also has a 10K pull-up (I guess the built-in pull-up would be sufficient).

So why does the connected J-Link (in particular the NRST wire) prevent the startup of the STM32F746? I didn't have these kind of problems with a F722.

[waclawek.jan]

> So why does the connected J-Link (in particular the NRST wire) prevent the startup of the STM32F746? I didn't have these kind of problems with a F722.

If NRST is pulled low, mcu does not run, regardless of what pulled it low. So this is probably a question to be asked at Segger's support.

JW

[Lars Beiderbecke]

I checked the level of the NRST wire connected to the J-Link device, and sure enough, it was LOW. But as soon as I connected the Tref wire with HIGH, NRST also went HIGH.

So my guess is that Vdd in above connector is not properly connected to Vdd, although there is clearly a connection in my layout. Maybe the Tref wire itself broke. I'll check further.