Code runs fine after `st-flash write`, but not after reset

[GSpre.1]

I'm using the template code for the STM32F7508-DISCO from the STM32CubeF7 repository with the only change being that I add a LED toggle and a busyloop to an infinite loop in `main`. The startup code and everything else is per the template.

If I flash the device with `st-flash write`, I verify that the code in question runs fine (the LED flashes in accordance with my loop and busy-wait). However, if I power-cycle the board, or issue `st-flash reset`, or start `st-util` (which also resets the device), the device seems not to do anything (no flashing). This is hard to debug, as attaching the debugger resets the board into the bad state.

Does anyone have any suggestions for what I could be missing? Again, everything works fine fjust after flashing the device. Resets, both hard and soft, fail.

[DBank.2]

I am not familiar with this setup, but have you got release and debug versions of the code compiling correctly and are you programming the correct one?

(I've seen this cause strangeness with other systems in the past).

Sorry this is not too helpful, but someone has been commenting on my question and I felt obliged to at least try.

[GSpre.1]

Adding the following interrupt handler fixes things, but I don't understand why:

void TIM6_DAC_IRQHandler(void)

{

 HAL_TIM_IRQHandler(&htim6);

}

[Tesla DeLorean]

For the DISCO/DK board it probably isn't BOOT0 being High or Floating

Check the address you're building the code for, the processor starts from a very specific location.

Check that it is not getting stuck in Error_Handler() or HardFault_Handler(), many cases of "not running" in fact are running, but fail for some reason.

Check you're enabling the GPIO clocks for the pins you're using, the loader/debuggers may enable pins they are using.

[Tesla DeLorean · Accepted solution]

An unserviced interrupt will re-enter continuously, or fault.

[GSpre.1]

Ah, thanks! I stupidly thought the weak stub I had in place was a no-op.