Looking for guidance on an approach to executing either of two runtime/boot-time selectable images stored in Flash (using OTP, or another technique). The two images would potentially be slightly different verions of the same application.
Envision this involving a standard boot from flash where a very small routine would query for the desired boot version whereafter the desired copy of the application would then be loaded. Running from Flash may be a possibility, either for the initial small querry routine, or for the application.
TMS320F28335
Hi Greg,
I don't see why you can't do that or I don't understand the question completely. Once the device boots to flash it is in appication domain and customers could put whatever code they want -right? As you mentioned you could use boot-to-flash or boot-to-otp option and have a small routine which is called from the default entry point, this routine finds and starts the right application within flash or can call back any peripheral loader as it seems fit for your applicaiton.
If you choose to use boot -to-otp option, make sure you validate the function properly before programming it in OTP.
Please refer to http://www.ti.com/litv/pdf/spru963a - bootROM guide for the device and let us know if you have any queries.
Please let us know if you have any clarifications.
Best Regards
santosh
Greg,
I'm curious how you intend to decide which image to load? Unless you only want to boot the second image after a warm boot (i.e. power not removed) RAM is off limits for making the decision. This leaves a GPIO or a bit in flash. Keep in mind that flash can only be erased in sectors, so if you are planning on using a bit in flash to make the boot determination you'll have to erase and reprogram a whole sector.
Trey
Trey German
C2000 Applications
The original idea was that one would be the default image and the other used for continued develpment and evaluating the effect of modifications.
When you say that RAM is off-limits unless we only want to boot the second image after a warm boot, are you stating what may be the obvious, that only booting from RAM can occur in a warm start, and booting from Flash can not occur in a warm start ?
With regard to the two alternatives, either a GPIO pin would be programmed to be used as an "input", or each time we needed to change the choice of image to load a sector in flash would be re-programmed (including a single image selection bit), and the GPIO input or the bit in flash would be read and used to indicate the image to be loaded. Can the GPIO Control registers be set up prior to booting ? What would the control flow look like, including the instruction (and its location) to read the bit in flash or the GPIO input, and the instructions (and their location) which use the bit indication or GPIO indication to load the selected image ?
When I was talking about RAM I was also referring to using that as a image selection mechanism. Your application could potentially check a bit in RAM to decide which image to load, but this bit would only be valid after a warm boot. I'm not referring to actually booting from RAM.
Given the flexibility you are looking for, I would recommend you use a GPIO to make the boot decision. From your questions it sounds like you have the impression that there is a mechanism in place to do this dual boot, but this isn't the case. There is only a single boot to flash vector, so initially there is only one execution path until the chip starts to execute your code. What you really need is a small flash bootloader which will perform the GPIO check and then branch to one of the images. If your applications don't use up the entire flash I would recommend you put the bootloader in one sector and the two applications in other sectors. This will help to keep the code compartmentalized.
To answer your questions directly:
No the GPIO registers cannot be setup prior to booting, but your bootloader may set them up just like it were an application when it is trying to make the boot decision.
Boot flow:
Power up -> BootROM executes and boots to flash -> Greg's bootloader configures GPIO -> make boot decision -> branch to one of two images in flash -> Greg's main application runs.
You can use the normal controlSUITE software to write this little bootloader as well as your application.
Regards,