Reset problem when swapping from bank 1 to bank 0

[daniel8]

Posted on November 06, 2009 at 11:56

Reset problem when swapping from bank 1 to bank 0

[daniel8]

Posted on May 17, 2011 at 09:59

I see the errata - The FMI_CR is cleared, while the address registers are not.

I have devices already on boards that use Rev G. I do have an upcoming build that I can make sure I am using rev H of the chips.

Do you have sample code for the redirection of interrupts instead of remapping the registers? I need to have a boot loader, so using a tool is out of the question. Thanks

[daniel8]

Posted on May 17, 2011 at 09:59

I have a problem with the system I have . I implemented a bootloader on Bank1 to jump to Bank 0 . That is working fine. The problem I have is when a reset hits. If i am booting off Bank0, a reset does what I would expect. When booting off bank 1, when a reset hits, the system gets into this unknown state.

I know the reset does not clear the sys status, FMI registers and clock config - but i am at a loss as to why things do not run. It can boot off 0 just fine and reset. if I keep the boot loader running (without jumping to bank 0), i can reset.

Any ideas why after I jump to bank 0 the system stops accepting a proper reset without hanging? Thanks

[tomas23]

Posted on May 17, 2011 at 09:59

The issue is with enabling different banks (0/1) vs. boot/non-boot. After the reset occurs, the boot bank (1) is not enabled and system hangs due to second fault.

The solution to your trouble is a) update the MCU to newest datecodes, or b) don't remap on the fly, better use fixed remapping of bank 1 with some tool and somehow forward the vectors to user application (eg. RAM jump table, needs some cooperation with user application)

[omniprintinc]

Posted on May 17, 2011 at 09:59

If you have Flash bank 1 configured as the boot bank and never change the mapping of the Flash banks so the exception handlers are always executed from bank 1, you need to have some sort of flag, say in a particular RAM location known by both the loader and the application, in order for the exception handler's to know whether to execute the loader's ISR or the application's ISR. The problem with this method is an unexpected reset will cause the loader to start executing but this flag will still be set such that the exception handlers think the application's ISR is still the one that should be executed. This will likely cause major problems.

The other approach is to boot from bank 1 then remap and start executing from bank 0. When you want to reset (say to run the loader code) you explicitly remap the Flash banks to run out of bank 1 again before you reset (note that code to do this must be executed from RAM) and you will reset cleanly. The problem again is an unexpected reset from bank 0 causes the chip locks up as you have already discovered.

In either case you are potentially screwed. The only real fix it seems it to update to a rev H CPU die.

[daniel8]

Posted on May 17, 2011 at 09:59

The issue isn't ''when I want to reset'' - The watchdog timer might be activated, the code might hang, a power glitch might reset without taking down the power - you can't know when you will want to reset.

I am not sure the ram thing works. if I relink the code to start at address 0x8000, and remap the vectors before jumping to 0x8000, that might do the trick.

I still gotta check and see the best ways of getting that done. It would be great if someone had an actual workaround example done, since I am not sure even if this method will work.

[fabio239955_stm1_stmicro]

Posted on May 17, 2011 at 09:59

I had the same problem.

Look at this thread http://www.st.com/mcu/forums-cat-5896-21.html

Fabio

[ This message was edited by: fabio.balzarro on 06-11-2009 16:27 ]