I have a MCBSTR9 eval board and in the process of implementing a bootloader. The bootloader boots from bank 1 and once it has finished with the firmware upgrade, it should remap the flash controller to boot from bank 0 and do a system reset. I could not get this to work. After digging around, I found out from the ST website that the STR912FAW44 has a flaw on the chip, where it doesn't reset one of the FMI registers. This flaw causes flash controller to retain it's current configuration(booting from bank1). The system reset does not to reset the peripheral registers and hence the system still think it's booting from bank 1.
I am trying their workaround and they (ST) suggested to boot from bank 1 and DON'T remap the flash controller to boot from bank 0. But rather, jump to a hard address in bank 0, i.e. 0x80000. I had compiled my main application mapping all of the code to start from 0x80000. At 0x80000, the reset handler for the main application resides here. I am not sure whether I should even have a reset handler for the main application since, I am just jumping there to execute code. I am also not sure whether this will work or not because I've checked the MAP file and this section's attribute is marked as read-only. Is it possible to execute code from a flash memory region declared as read-only? I don't know how to change the flash memory section attribute to allow it to be executable.
I keep getting caught in the Prefetch Abort Exception as I jump to this address 0x80000. Could this be that the memory attribute is read-only?
Couple of main questions:
1) Is it possible to run this scheme? { Assumption: YES }
2) Do I need the reset handler in the main application based on my scheme? { Assumption: NO }
3) How can I change the flash memory region to be read/write/execute? { Assumption: ??? }
Thanks, Tom
It is just amazing to see how much trouble the STR9 is causing to so many people that try to write a bootloader for it. I never did (but for an LPC2478 which does not have this bank concept) but I promise to try and to report here (or a new thread) if I get it to work.
The problem lies in the hardware itself as I have stated but I think the people facing the problem with the software workaround.
There is nothing wrong with RO for code. How do you load your program to address 80000? How you know if it is loaded properly?
Hi Mikhail,
Thanks for your response. I have actually gotten booting from bank 1 and jumping to bank 0 scheme to work, since I've last posted this problem. The main glitch in the above problem is that the STR91xFAxx also have an issue with write/read/execute between the two flash banks. The reason why I was faced with the Prefetch Abort Exception is resulted from this issue. As the software workaround recommended by ST, the PFQC bit should be turn off before the access to the different bank. In my case, I turn off the PFQC bit, then jump to bank 0. In the bank 0 code, I re-enable this bit. This will handle the Prefetch Abort Exception problem for jumping between flash banks.