STM32F030: Interrupt remaping to RAM

[rajeevkumar7290]

Posted on April 28, 2017 at 04:33

Hi,

I am developing bootloader for STM32F030ccT6 to upgrade my Main Application through OTA. There are two application within my controller flash one is BOOTLOADER( @ 0x08000000) and other is Main Application( @ 0x08001000 ) .

Now I have done Jump from Bootloader to Application and running one 2 USART and 2 Timer Interupts of main application correctly. But here is a problem with NVIC_SystemReset and IWDG may be some other also but i checked only these two.

Actually when I reset Main Application using 

NVIC_SystemReset then it calls reset handler of Bootloader. But as i think it should call reset handler of Main Application rather than Bootloader.

 Please give me suggestion for this different bahaviour with NVIC_SystemReset.

[rajeevkumar7290]

Posted on April 28, 2017 at 04:53

By mistake I posted this in 'share my activity' also. And thanks for Clive for response on my query over there.

In that case, system not execute nvic_systemreset by itself. It is my need means I want to soft reset my main application whenever need. (1) But as I observed that it goes to boot loader reset handler instead of main application remapped vector table which is in RAM. So what I am asking that calling to BL reset handler is right or it should go to only main application reset handler only. Anyways I have no big problem over this because I can jump again to main application by checking a key value, stored in eeprom, so that which app I have to run.

(2)But it should not affect the other interrupt handler like this. I check for IWDG also its reset also goes to BL vector table.

(3) I noticed also that 0x00000000 address mapped correctly to RAM 0x20000000 but when performing __DSB() inside NVIC_SystemReset fn then 0x00000000 gets remapped to BL vector and jump to BL reset handler but I called it for reset the main application only and for that it should go to main app remapped vector.

Thanks for your support in advice and

And what is the magic value?

[Tesla DeLorean]

Posted on April 28, 2017 at 08:09

Does it call the application if you cycle the power?

No? So should a RESET do the same thing or something else?

[rajeevkumar7290]

Posted on April 28, 2017 at 11:39

Dear clive, 

i did not get your point what u are asking.

As a whole system integrated with BL(0x08000000) and Firmware(0x08001000). After powered up system start run from location 0x08000000(start of Bootloader) and then i init Timer IRQ and an USART Rx IRQ. And if CMD received from usart then it jump to Firmware. In Firmare, i mapped the Firmware vector table vector to RAM and also confirmed it on address 0x00000000. Now system running okey with new Timer and USART interrupt Handler.

Here i want to include a feature of soft reset. And i performed this by NVIC_SystemReset on basis of USART received request. Now it jumps to BL reset handler and 

0x00000000 referenced again to 0x08000000 vector.

My query:

1. is this kind of calling of reset handler right?

Because i want this to reset my main Firmware only not with BL.

2. why it is reseting BL also?

[Tesla DeLorean]

Posted on April 28, 2017 at 13:51

You are resetting the entire system with NVIC_SystemReset(), it pulls the NRST pin low, like pressing the RESET button externally. Strong defined behaviour occurs.

It doesn't, and won't work the way you dream that it should, and arguing what you think is should do so will not alter reality. Plan accordingly. If the BOOT0 pin is low theprocessor reset will enter the code described at 0x08000000, at that point you have control of what happens next.

Magic value, a value you choose that has significance, the code in the Reset_Handler of the Boot Loader can recognize and expedite entry into some other code or region, here it redirects to the ROM on a different part, but could just as easily transfer control to the SP/PC described at 0x08001000

https://community.st.com/0D50X00009XkezoSAB

Your application could branch to the Reset_Handler code of the application if you want, make sure the code there sets the SP to __initial_stack.

ie extern void Reset_Handler(void); ResetHandler();

This however fraught with issues because it doesn't change the state of the processor or peripherals, and there are many traps from the unwary.

https://community.st.com/message/155422-interrupts-remapping-issue-in-stm32f0xx-for-nvicsystemreset