To help overcome this, and to simplify my own (wishfully planned) development on the Nano, I have written a small bootloader extension to the original USB DFU bootloader. The code is at https://gitorious.org/dsonano/dso-bootl
It currently adds these features:
- 1. Let any application decide which application should start after reset (think boot selection applets here).
- 2. Allow DFU downloading to RAM. This also uses (1) so that an application can be downloaded and run from RAM.
Later I will provide a "hello world" example for running from RAM.
More info in the README file at https://gitorious.org/dsonano/dso-bootl ... oot/README
If several applications become available on the Nano, it might call for some agreement between developers in order to simply multi-boot. I would suggest the following:
- 1. We will avoid having to reprogram the original bootloader, since that can be a support burden. This leads to 2:
- 2. No application should install in the first page at 0x08004000. This location is called from the original bootloader so the (link to a) new bootloader or application selector must be installed here. Otherwise the application in question must provide the multiboot selection facility.
- 3. To allow space for more applications in flash, try to pack code segments together, because holes are difficult to use.
- 4. Some convention for a identification tag or title that can be scanned for and displayed in a boot selection applet.
Also, the calibration data resides 4 KB below the upper flash memory limit. Maybe it can be shifted up as high as possible so that other applications have more contiguous space? If it needs space for future growth, it can grow downwards.
Regarding (2) the LIB can simply be shifted one page up. The application provider can ship a separate 1-page image file to install in case there is no boot selection facility installed on the device. The 1-page image just needs to contain a copy of the 8 first bytes of the LIB image.
Looking forward to your comments, ideas, and... new applications