cancel
Showing results for 
Search instead for 
Did you mean: 

irrelevant information on serial port when I jump into FLASH APP using my IAP?

fujiangmu
Associate II

fujiangmu_0-1769570775488.pngfujiangmu_1-1769570844224.png

 

10 REPLIES 10
TDK
Super User

My guess is your application writes to UART1 as well.

Nothing wrong that would explain this in the code you've shown.

If you feel a post has answered your question, please click "Accept as Solution".

FLASH APP? It's only in EXTI2_IRQHandler().

But I didn't trigger the interrupt.

fujiangmu_1-1769581694089.png

 

LCE
Principal II

Disable the EXTI interrupt before the jump.

At least on a H7 a lot of de-inits and interrupt disabling is done before jumping.

Maybe before jumping you first de-init / change the GPIO config, and that triggers the EXTI interrupt.
So try to disable EXTI first, the de-init the GPIOs.

LCE
Principal II

BTW, so many (and long) for-loops in an ISR are usually not considered good design, unless you have some very specific reason for that.

Why not just set a flag and then "print" in the main loop?

It still stuck.

fujiangmu_2-1769591301219.png

fujiangmu_4-1769591529159.png

fujiangmu_6-1769592011313.png

 

 

 

If I set a flag,it is not timely enough in some condition.For example, more than 2 interrupts occur simultaneously.

 "print" in the main loop is DMA or other methods?

LCE
Principal II

With "print" I mean any kind of UART output.

You could trigger a DMA UART TX in the ISR, then you don't have to wait there.

LCE
Principal II

I'm not sure if I understand you correctly, right now it seems that the jump to the bootloader happens from within the ISR without any de-initialisations?

It sure looks like it did. The code in your interrupt is exactly what you show in your screenshot. I would recheck your assumptions here.

If you feel a post has answered your question, please click "Accept as Solution".