I don't know for this particular derivative as I never used it, so just generally:
- if the original bootloader has no suicidal tendencies and can be invoked by a hardware condition under any circumstances (as far as it is not modified in the parallel programmer), I would leave the "accident" problem to this - it might require "manual" intervention (e.g. flipping some jumpers) but should occur seldom. Of course, this does not apply if the application should be ultimately able to be updated remotely with no user intervention (e.g. installed under sea or so), but here the measures taken should be far more thorough.
- I would place the new bootloader in the user flash in a suitable place so that the application itself could be modified easily
- I would read up the intelhex specification - there are extensions how to map memories beyond 64kB
- I would use these extensions to distinguish between the internal and external memory in the bootloader, and would use only a slightly modified original bootloader for it (in this way, for reprogramming only the internal memory FLIP still can be used)
- I would consider external memory as if mapped from 0x10000h up
- there are programs around, able to manipulate hexa files - remap (the external memory: address+0x10000) and merge (the internal+external memory + control commands - the latter don't need to be "merged", instead, simply added) - they are often command line tools so can be combined writing simple "scripts" (batch files)
- for programming, I would use any terminal program capable of delaying between lines; my favorite is TeraTerm for which I wrote a macro as a simplistic ad-hoc replacement of FlashMagic (FLIP's equivalent for Philips derivatives) - see at my webpage. I don't like PC-side programming, that's why I am trying to avoid it as much as possible and use what is readily available instead, even if it needs to be modified/abused a bit. Your mileage may vary.
I am afraid this was not too clean, but maybe some of it would help a bit.
Jan Waclawek
