STM32F767 stuck in hardware reset loop

BGee · ‎2018-09-24

I can connect with JTAG via SWD and load a simple program but after load the system won't run to main. The chip seems to be stuck in some hardware system reset loop. Attached is an image of the nRST pin. I've gone through AN4661 many times and can't figure it out. Power rail looks good and I have BOOT0 strapped low, PDR_ON strapped high. Any ideas?

Bob S · ‎2018-10-02

As AvaTar mentioned before - run the debugger on that bootloader code (or LED toggle code) and see what happens. You will need to figure out how to tell your IDE to NOT "run to main" but instead allow you to single-step from the reset vector.

Also, check the option bytes using whatever programmer you are using, specifically the "user configuration" bytes. Is it possible that when programming the custom bootloader that somehow the option bytes got changed to enable one or more watchdog timers? Or change the boot selection options? I don't THINK this is your problem because the reset period looks the same as your first scope screen shot. But these are (or should be) easy things to check.

Also check the brown-out reset voltage in the option bytes and make sure it matches whatever power supply voltage you are using.

Otherwise, double-check for some kind of power supply issue. Is the 2.2uF cap you added/changed still attached with good solder joints?

View solution in original post

T J · ‎2018-09-24

Is you power supply large enough ? maybe the 3V rail is dropping out.

Are you power supply wires too thin ? and no capacity ?

Do you have a power supply supervisor on the board ? can you check the 3V rail for spikes at 10nS ?

Did you enable the watchdog ?

Is it a LQFP part ?

is it your own design ? with BGA ? maybe the pins have fractured off.

BGee · ‎2018-09-24

Watchdog is disabled. Here is a picture with the 3.3V power rail (blue trace). Yellow trace is the nRST signal. I zoomed in to 10ns divisions and there is no drop on the rail.

T J · ‎2018-09-24

what power supply do you have ?

there will be switching noise. at about 10-30MHz

adjust the scope to AC, ramp up to 100mV per division.

set the trigger to normal, not auto

adjust your trigger level to the minimum before it stops triggering.

what package is it ? BGA or not ?

is it a custom board ? how many did you make ? are they all doing it ?

how old is the board ?, did it work before ?

do you have a reset monitor chip on board ? can you remove that ?

Tesla DeLorean · ‎2018-09-24

This presumably your own design?

Does it do this with BOOT0=HIGH ?

What voltages present a VDDA and VCAP pins/caps?

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

BGee · ‎2018-09-24

Yeah, custom board.

Will test with BOOT0 = HIGH.

VDDA = 3.3V

VCAP = 1.2V with odd ripple (see trace)

I am using this LDO. Micrel - MIC5332. https://www.digikey.com/products/en?keywords=576-4110-1-ND (3.3V 300mA).

3.3V Power rail ripple

T J · ‎2018-09-24

power is probably not the cause,

although I have never seen a power supply working so hard as yours is..

are you light on capacitors ? did you use good capacitors ?

can you redo that last pic across a Vdd-Vss Cap next to the processor ?

and again Vdda Vssa Cap.

( I mean to move both the scope "ground" and "probe", right across the capacitor.)

BGee · ‎2018-09-24

Sounds like bulk and bypass capacitance might be the problem.

On the output of the MIC5332 is 1uf, 0.1uf, 10uf network.

On VCAP1/2 I have 0.1uF. Datasheet shows 2.2uF (This might be the problem)

On the VDD pins I have 0.1uF on each pin and then a 1.0uF bulk, (Could probably use more?)

Scope trace with smaller loop across vdd/vss. The vdda/vssa looks the same.

T J · ‎2018-09-24

yes it looks much better

yes, 2.2uF is necessary.. 1uF is just too light.. they requested low ESR in some datasheet

Then, around the processor, I use a 0.1u and a 1u as you do, it works well.

T J · ‎2018-09-24

can you check the temperature of the MIC5332 ?

how much current are you pulling ?