STM32F746 "forgets" flashed program (and more)

Lars Beiderbecke · ‎2020-12-14

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 · ‎2020-12-15

That was easy ... My Boot pin is connected to Vdd, instead of Vss (the section mentions start address 0x0020 0000, BTW).

Lars Beiderbecke · ‎2020-12-15

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

Andreas Bolsch · ‎2020-12-15

Well, there is no difference of "run time" to "not run time". The programming is usually done via a short program uploaded into RAM and excuted from there, so at "run time" as well. And, you can erase/write the flash at run time in your own application, too. The point is, your programming software must "know" that the area starting at 0x00200000 has in fact to be programmed in the area starting at 0x08000000, even if this might happen "under the hood" so that you didn't notice.

But anyway, problem solved ... ;)

Lars Beiderbecke · ‎2020-12-15

Good point, I didn't know that. But in that case I'm at a loss what the Reference is really hinting at ... Also why FLASH has no w when flashing does in fact write to it.

waclawek.jan · ‎2020-12-15

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

JW

Lars Beiderbecke · ‎2020-12-16

(nevermind)

MM..1 · ‎2020-12-16

FLASH cant have w, because cant write to one address and too cant write with one asm instruction as on memory mapped thinks...

And WJ maybe mean, that best answer is first not your. 8)

Lars Beiderbecke · ‎2020-12-16

Yes, I was going to write later ... While my BOOT pin was wrongly connected, fixing that didn't solve my retaining problem. So I'm going to test 1) today.

Should this work, I guess I'll have to add an RC element to ... Vdd for STM32? That makes sense, since I migrated from low-drop regulator to step-down regulator. But adding an RC element to Vdd will be difficult, since right now I use a Vdd plane. And my step-down regulator doesn't allow to control startup speed.

MM..1 · ‎2020-12-16

RC makes slow start on Vcc slower, this dont help you. You need quicker rising edge or circui for check Vcc and reset MCU externally.

Check your stepdown, maybe have solution for quicker start or power good out aka reset.

Lars Beiderbecke · ‎2020-12-16

I see, I thought you meant it is too fast. I'm not really sure how to speed this up; the only extra features my step-down regulator has are "power good" and "snooze mode" (which is disabled). Maybe I should get a different power regulator, although the TPS62082 by TI seemed pretty modern.

Maybe I could also add an auto-reset feature, but I think it would delay the startup of the STM32 too much.