IAP flashed program stuck in ADC_IRQHnadler

[Renato Valentim]

I've managed to finally get the IAP flashing a new netlist with LwIP for the STM32F767 Nucleo Board. But now the program is getting stuck. I made a new program (of which I included the temp1.txt file which is the equivalent of the temp1.list file). It simply blinks on and off an LED. (using HAL_Delay). it works when I load it directly on the STM32F767 Nucleo board.

But when I load it through IAP and I run it, it gets stuck. When I press "Pause", the IDE shows shows:

that the program is in 0x80209c0 (ADC_IRQHandler):

080209c0 <ADC_IRQHandler>:
 * @retval None       
*/
    .section  .text.Default_Handler,"ax",%progbits
Default_Handler:
Infinite_Loop:
  b  Infinite_Loop
 80209c0:	e7fe      	b.n	80209c0 <ADC_IRQHandler>

It was executing HAL_Delay (0x80208cc) but inexplicably it seems it goes to this ADC_IRQHandler and it stays there in Infinite_Loop:

Does this mean I cannot have HAL_Delay in my program that I want to flash using IAP?

Thanks

[Tesla DeLorean]

Default_Handler is the dumping ground for dozens of weak interrupt handlers that lack proper bodies in stm32f7xx_it.c

If using .cpp, or compiling as C++, watch for name mangling. Check your map file, and listing file.

[Renato Valentim]

I'm compiling for C. I look ed the .map file. Nothing seems wrong. It works when the program is flashed by the IDE directly, but when running from the IAP program, it always crashes in the same lines. I don't see what interrupt it is trying to handle.

[Tesla DeLorean]

Likely because you have interrupts enabled on the loader side which you aren't handling on the application side.

Normally you would go through the peripherals and get them into a safe state before transferring control.

Diff the stm32f7xx_it.c for both sides.

Split the WEAK interrupts lists into halves so you can bisect which specific interrupt you're not taking ownership of on the application side.

[TDK]

Look at the ICSR_VECTACTIVE bits and subtract 16 to see which interrupt is active.