F4 Sporadic reset into DFU and DFU jump. Any links between power and DFU?

[arro239]

at rusEFI we enjoy both hardware DFU jump (boot0 + reset buttons) and software DFU jump (breadcrumb with system reset)

Everything was great until we got a fresh batch of assembled devices with very minor changes.

Now hardware DFU (boot0+reset) reboots us into DFU only on 80% of occasions. All the devices previously would just go into DFU on 100% of occasions not below that.

Now if device is powered from USB software DFU does NOT happen in 95% of the reboots to DFU - we get the MCU to reboot just not enter DFU, as long as powered by USB only.

If we power the device by +12 with on-board power supply suddenly we have software DFU working as expected.

This makes me wonder if there is any relationship between DFU bootloader and power? voltage? else? I am sorry if that all sounds insane.

out test notes at https://github.com/rusefi/hellen-NB2-issues/issues/5

Schematics for both revisions linked at https://github.com/rusefi/rusefi/wiki/Hellen72

[TDK]

There's no link between voltage and whether the chip enters the bootloader or not. Look for a solution somewhere else. How do you know it's not in the bootloader?

When the chip doesn't go into the bootloader, where does it go instead? Attach a debugger, view registers.

[arro239]

We now suspect it's something about USB being connected to 407 but not 427: hardware DFU works REALIABLY if laptop is unplugged from board, and HARDWARE reset to DFU is UNREALIBLE if laptop is attached via USB.

We believe that DFU bootloaders is running for about 800us and then it reboots itself into normal load - so DFU does start it just that it quits?

so far all F427IGT6 chips are working fine. We've even moved a F427IGT6 to a board which was affected while it had STM32F407IGT6 and the issue got resolved. So either we got a funny batch of 407 or something is different between 407 and 427 in this regard?!

[arro239]

We are more and more convinced that it's about 407 vs 42x differences. We are now focused on oscillator behavior see https://github.com/andreika-git/hellen-one/issues/79

Schematics of the reusable MCU block page 4 of https://github.com/rusefi/hellen121vag/blob/main/boards/hellen121vag-b/board/hellen121vag-b-schematic.pdf

[arro239]

we've now narrowed it down to "oscillator takes too long to lock"

[arro239]

Plan is to swap oscillator for a different part number

We believe that F407 DFU allows only for 800us to detect external osc and then reboots while 42x waits longer and survives our longer starting osc

more or less same thing between 401 and 446 in https://community.st.com/s/question/0D53W000004lc5NSAQ/dfu-over-usb-not-working-hse-not-detected

[Max]

Maybe this is linked to the embedded bootloader version:

V3 on STM32F407 and STM32F401

V7 on STM32F427

V9 on STM32F446

Check AN2606 for details

[arro239]

I have replaced 8MHz osc with a 20 MHz osc and the issue seems to be resolved!

I am now using ABM3-20.000MHZ-B2-T

along the way we've implemented auto detect of HSE speed https://github.com/rusefi/rusefi/commit/15353ae3b26274bf300dab34719ac506d3612eb7 in the firmware