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]

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.

[Lars Beiderbecke]

Actually, I was wrong with my analysis, and you all were correct, except that in 25% of cases the STM32 starts normally. In the other 75% of cases, a manual reset does the job.

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).

According to the step-down regulator datasheet: When EN is set to start device operation, the device starts switching after a delay of about 40 μs and VOUT rises

with a slope of about 10mV/μs. That implies that the target voltage should be reached in less than 400 us.

Is there any way to speed up that particular regulator? What could cause the delay? If the curve kept the intital slope, everything should be fine. Should I get a different regulator?

[Lars Beiderbecke]

What I'm trying to do now is to set the Brown Out Reset (BOR) of the Power Supervisor to a higher level. There a two bits in the FLASH_OPTCR register I need to set.

Now according to the Reference, the FLASH_OPTCR is found at 0x1fff0014, but apparently also at 0x40023c14. Looking at a JLink script to set the BOR flags, it writes 0xaa, 0xbb or 0xcc to 0x40024c14 (the BOR flags have a weight of 0xc).

Why are these values used, instead of just 0x0, 0x4, 0xc? It seems that the script is also affecting Reset and Watchdog flags (and 0xa, 0xb affect the BOR flags the same).

[Lars Beiderbecke]

Nevermind, these writes are for a different feature (Read Protection), in my case I need (for example): w1 0x40023C14 0xF5.

[MM..1]

Put Segger to trash and use STLINK utility GUI. 😉

[Lars Beiderbecke]

Yes, but then I would have to read up how to turn a Nucleo into a stand-alone flasher. Besides, is the GUI any better when it comes to addresses and values to flash?

I think I flashed FLASH_OPTCR with the J-Link to Level 2, although I should also read it back to confirm. It did not have an effect on STM32 startup, though.