Wouter van Ooijen wrote:

>> Which makes me even more agree with Olin... Use a transparent bootloader
>> and control your flash write routines, or link your programs for your
>> bootloader. 
>> 
>> If you can't do either, get a programmer :)
> 
> No, IMHO there are places and times when a bootloader is appropriate,
> even if it can't fully protect itself. In a classroom for instance,
> where re-installing the bootloader can be a matter of seconds. But not
> when the students are supposed to work at home too.

But in that case you can choose to link the programs for running with a
(fully protected) bootloader. IMO there's no need to work with a
transparent bootloader in a classroom -- you control the environment. (And
if you, for some reason, think that a transparent bootloader is better,
then the students /have to/ control their flash write routines to not touch
the unprotected bootloader areas. That's just a simple fact -- the ones who
don't will need a programmer :)

So I still think this holds: Either use a transparent bootloader and
control your flash writes (so that you don't overwrite the reset vector and
the separate code area that your bootloader uses outside of its protected
memory area), or use a normal (fully protected) bootloader in the boot
block and link your programs for running with your bootloader (that is,
with an entry point and interrupt vectors above the boot block), or -- if
you can't or don't want to do either -- get a programmer :)

Gerhard

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist