This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Switching code and data flash

Hi all,

I am writing an application using a 512kb program flash and a 512kb data flash. When doing the firmware update I have the luxury that it is OK to loose all data in the data flash. So what I would like to do is to store the new firmware version in the data flash and after verification swoop the two flashed so the data flash now becomes the program flash and the program flash gets reinitialized and becomes the data flash.

Does anyone have some experience doing this?

Thank you,
Dennis

Parents

  • You also need to consider how the system will begin execution from power on. If you have some magic chip select logic to select the current program flash, then you you'd need a non-volatile hardware bit to remember which flash that was so that you can start fetching from it immediately after power up. Where does the instruction after reset at address 0 come from?

    It may be simpler always to have a boot loader in one particular flash; that code always executes at power on and can then examine both flash parts and decide which one has the current application load, and which one is used for other data. The app load might swap back and forth, but the boot code always stays in the same flash.

    If you execute from RAM, you can copy the appropriate app load from either flash. If you execute directly out of ROM, then your boot code will have to program the chip select logic and jump to the app load, which probably implies that the load will have to be relocated to the same addresses and live in the same address range in both chips. Since you've got to give up a little space for the boot code, there will be a little piece of the "program" flash unused when the app load lives in a different flash than the boot code, and the boot code will be taking up a bit of the "data" flash.

    (If you really need the entire 512K for data, that unused section in the "program" flash can be used for data. And if you want to get really weird, your address decoding logic could even decode the lower "boot code" addresses of your flash parts differently, so that the data area always appears to be one contiguous region even when it's split between parts. Such decoding ought to be done on flash sector boundaries, and you'll want to stay away from the "chip erase" flash command, in such a case.)



Reply

  • You also need to consider how the system will begin execution from power on. If you have some magic chip select logic to select the current program flash, then you you'd need a non-volatile hardware bit to remember which flash that was so that you can start fetching from it immediately after power up. Where does the instruction after reset at address 0 come from?

    It may be simpler always to have a boot loader in one particular flash; that code always executes at power on and can then examine both flash parts and decide which one has the current application load, and which one is used for other data. The app load might swap back and forth, but the boot code always stays in the same flash.

    If you execute from RAM, you can copy the appropriate app load from either flash. If you execute directly out of ROM, then your boot code will have to program the chip select logic and jump to the app load, which probably implies that the load will have to be relocated to the same addresses and live in the same address range in both chips. Since you've got to give up a little space for the boot code, there will be a little piece of the "program" flash unused when the app load lives in a different flash than the boot code, and the boot code will be taking up a bit of the "data" flash.

    (If you really need the entire 512K for data, that unused section in the "program" flash can be used for data. And if you want to get really weird, your address decoding logic could even decode the lower "boot code" addresses of your flash parts differently, so that the data area always appears to be one contiguous region even when it's split between parts. Such decoding ought to be done on flash sector boundaries, and you'll want to stay away from the "chip erase" flash command, in such a case.)



Children
No data