Executing code from RAM (without LX51)

The app header doesn't need an entire sector of flash to itself. Why not just put your header at the start (or end) of the app flash area? Your boot loader is copying the code from flash to RAM anyway, so the app code doesn't have to start at any particular place in flash; that's up to your boot loader. The app will be located for its final address in RAM; its address in flash is irrelevant.

the best bootloader schemes of mice and men do make sure that ANY power glitch at ANY time during upload will not leave a dead device.

The more you include in the boot procedure, the greater the risk / the more careful you have to code - your choice.

Erik

Andy,

What you do here depends a bit on how big your main application is going to be. If it just consumes a single main flash bank (32kB), then you can actually have MORE than one application programmed and just use some technique to mark which one is valid.

What I'd recommend is this: Within your application, make a C code constant named, say, statusbyte that is initialized to 0xFF. Put this in its own module and have the linker locate it to a known address. Use the LSB to indicate whether the application has been programmed (that is, if it is "0" the application exists, or if it is 1 it does not). When a flash is blank and all 0xFF's your startup code will know that there's no app there. Have another bit (maybe the MSB) represent "image bad." It's important to have this distinct from the "image good" bit since without erasing flash, all you can do is set bits to zero, not back to 1.

When you program a flash bank, do your checksums right then and there and if everything looks ok, program the "application exists" bit of your statusbyte to a 0 to indicate that the application exists. If you previously had an application in another bank, then program ITS statusbyte's "application bad" bit to 0. This way your startup code can do the following: 1. Check application area 1's "application bad" bit. If it's zero, check application area 2's "application bad bit. If it's also zero, just stay in the bootloader and wait for a download.

2. If one or more of the areas has an "application bad" bit set to one (meaning the application might be ok), check the "application exists" bit to make sure it's zero. Just run the first image that has this bit set to zero.

I don't know if that makes any sense, but it's one way to make sure that A.)If your IAP fails, the previous version will still be runnable. B.)You can always recognize the latest successfully programmed application C.) You won't be messing around with the boot area and rendering your system unusable.

-Jay D.

I want to use a block of boot flash to act as NV storage for details about the image

Now what on earth would you want to go and do that for?

Why put pieces of information that naturally belong together, since they would only ever be changed simultaneously, into separate places like that?

It's quite a lot easier to keep that information as a header block directly in front of the application's image.

Hans-Bernhard

Is this really so crazy? This idea has been used successfully in the RedHat RedBoot bootloader where a table is maintained in the boot area if what images are loaded and at what addresses. The user can then configure RedBoot to boot a particular application. The checksum informaiton stored is used to validate that application prior to executing it.

Now as it turns out I only want a bootloader and a single app at this stage, but that may not always be the case.

Andy

Hi Drew,

Your reply didn't really make sense to me. Why do you think I am copying code from flash to RAM?

The way I am intending to acheive IAP is to run the bootloader from boot flash, use it to download an application into main flash, validate the app and then switch the VM register and 'reset' to begin execution from main flash thereby running the main app. I have read about this technique being used by a number of people - some of which are regulars this forum.

It sounds to me like you have an alternative and perhaps more flexible solution. What is your design and how does it cope with IAP? Are you saying that you copy your enire main application into RAM and execute from there?

Cheers

Andy

Andy,

uPSD33xx. is not a chip I use, but reading the above and having heard rumors that his chip is a NXP 'equivalent' I would presume that ST provides a bootloader.

Thus, in fact you are reinventing the wheel.

What I have done in the Ph ARGH!!! NXP area is creating the NoTouch (can be found at http://www.esacademy.com) which is a very simple way of invoking the 'factory provided' bootloader from serial data, keypress or whatever.

Have a look and, maybe, just maybe, such a method may be possible with your chip and be what you are looking for while not seeing the forest for the trees.

Erik

Erik,

I've used the uPSD family of products from ST quite a bit and they're not equivalent to anything resembling an NXP chip. They, in fact, DO NOT have a bootloader masked into ROM somewhere for you. The don't even have really solid information on how to get IAP done except for a one-page whitepaper.

Having done it already myself, I'm not surprised that Andy's having trouble. There are about 20 different ways to setup IAP for this chip and each have their strengths and weaknesses.

-Jay D.

Andy,

The title of your original post was "Executing code from RAM (without LX51)." This might have led to Drew's suspicions. :)

-Jay D.