On Thu, May 29, 2014 at 08:37:03AM +0000, alan.b.pearce@stfc.ac.uk wrote:
> > > That protection could be done with dsPIC's CodeGuard, but it is not
> > > available for other platforms, and I don't know how secure it is inde=
ed.
>=20
> Yes, it seems a shame that CodeGuard hasn't taken off, it seems a nice fe=
ature, rather like the memory protection mechanisms in mainframes, but appl=
ied to Flash memory.
>=20
> >=20
> > I looked at code guard for a different reason: protection from being
> > overwritten. Unfortunately my latest darlings, the PIC24FV families wit=
h 5V
> > operation and 20 and 28 pin DIP pinouts, only have basic protection. Th=
is
> > level is all or nothing in terms of protecting the flash.
> >=20
> > It doesn't work for my FORTH interpreter because I wanted to use part o=
f the
> > flash as a cache for the RAM between powerups. If there were a separate
> > boot segment, then the FORTH kernel could be protected while still allo=
wing
> > for the flash cache to be readable/writable. Alas that's not possible s=
ince it's
> > all or nothing. So right now I'm operating with the code completely ope=
n.
>=20

> Maybe you need to look at the 24E/33E series, which have an auxiliary
> memory area designed for bootloaders. Only trouble is they are 3v3
> devices, but have some 5v tolerant pins.

You completely summarized my reasons for sticking in the area that I've
been.

I think the alternative I may use for students is to completely lock down
the flash and have them add a SPI/I2C flash chip that can be used to hold
ram images and data blocks. The key is to up the reliability so that errant
code won't erase the kernel.

BAJ

--=20
Byron A. Jeff
Chair: Department of Computer Science and Information Technology
College of Information and Mathematical Sciences
Clayton State University
http://faculty.clayton.edu/bjeff
--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.