We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
This is a question to anyone who is expert in IAP programming. I am experimenting with relocating code on a Keil MCBSTM32 board. I have taken the "measure" example and have modified it so that through the menu system I can make a copy of it into the second part of the Flash starting at 0x8010000. During the copy I modify the IVT so that they all point into the relocated code. Then I can jump into the the modified image resetting the IVT offset to the new position as I go. This looks good as everything seems to run okay and it can report that its start address and main address is where I expect it to be. Now here is where it goes wrong. I try to erase the original image ( from the new running image ) and it all locks up. Also if I start again and switch to the new image and back to the old one, the old image can not erase the new one. It can do this if I do not do the jump in and out again. It locks up during the erase sequence during the Control register is set to STRT. e.g. FLASH->CR|= CR_PER_Set; FLASH->AR = Page_Address; FLASH->CR|= CR_STRT_Set; <--- locks here I have checked that the CR has not got the lock bit set and also done unlocks before hand just in case. At the moment I can think of two reasons why this may be. 1) There is still code ( maybe interupts ) running in those pages and the FPEC dies. 2) The FPEC thinks there is still code running in there and dies. Any one got any ideas, it does not matter how off the wall they are. I'm stuck.
All solved This was nothing to do with the FPEC not working correctly. I was just that my instrumentation was running in the wrong zone. Crash was down to stdio needing to be remapped to new zone. I have done this in a pretty brutal way when the image copy is being done where any 0x0800 half words are changed to 0x0801. This is pretty dangerous but at least it proves the relocation concept. I will resolve the exact address remapping later. What I have shown is you can bootload a new application from your currently running one and then jump into the new one directly. This allows 1) The old application to service important control loops during the upgrade process. 2) The new app can then be jumped into almost instantaniously again decreasing control downtime. 3) The old app can them be recovered just by jumping to it if and when required These may not be usfull for most IAP upgrades but it is for ours. :)
Thank's for looking.