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.

[Lars Beiderbecke]

Alright, my file now reads:

device stm32f746ie
if 1
speed 1000
con
sleep 100
w4 0x40023C08 0x08192A3B // Clear option lock 
w4 0x40023C08 0x4C5D6E7F
sleep 100
w1 0x40023C14 0xF5       // Set BOR (flash option control register)
sleep 200
mem32 0x1fff0000 1        // read back (Flash option byte)
sleep 200
r                        // reset
sleep 10000
q

I flash this with J-Link Commander, but reading the register with mem32 always returns

1FFF0000 = 5500AAFF

as if the write didn't happen. This also doesn't change with multiple flashes (in case the write needs a reboot).

But I don't get the different between Option Byte and Control Register. Should I swap both addresses?

[MM..1]

Mark best answer and create new thread

and How to reconnect nucleo to st-link part? - Electrical Engineering Stack Exchange

[Lars Beiderbecke]

Actually, let me just mention that I finally set it by splitting the writes, but the STM32 still won't start up.

[MM..1]

Now your thread is STM32F746 "forgets" flashed program (and more) ?

Or My Segger Jlink dont do what i mean?

Pls close this thread i stop read it and mean others have too problem ...

Use 6pin or only 5pin from six on Nucleo to STlink target connect and erase, programm over utility desired for STM32.

[Piranha]

> NRST, which also has a 10K pull-up (I guess the built-in pull-up would be sufficient).

There is one of the problems. Why is that pull-up there? Copy-paste design from BluePill or some other internet "marvels"? The pull-up on NRST is not just an ordinary pull-up like on a GPIO input. Together with the 100 nF capacitor on NRST it forms a RC circuit, which ensures a sufficient reset delay. Read the AN4661.

[Lars Beiderbecke]

While now irrelevant, I put it there because the built-in pull-up is weak, and -- according to some -- too weak.

Frankly, I don't get the need for a reset delay, when the brown out detector can handle this just fine.

[Piranha]

Pull-up can be too weak only if you hang dozens of chips on NRST line together sinking significant current. That is not the case with typical one to few chips. And even if pull-up resistance needs to be decreased,m capacitance should be increased accordingly.

POR/BOR will release the reset even from an extremely short glitch on power line. The RC circuit filters that out.

> Looking at the voltage rise, one can see that startup takes more than 1 ms -- in this particular case, the STM32 did not start up (1 grid cell is 1V/1ms, I used a 10x probe).

To me it seems that sufficient reset delay of few ms is exactly what is missing here.