On 12 Jan 2018 at 10:14, Anthony Nixon wrote:
> I'm using a PIC18F47K40. My reprogramming driver (from Windows)
> normally bypasses the boot loader, but in this instance I needed to be
> able to rewrite it without requiring a programmer.
The PIC16F bootloader I use is active for a short period of time at boot, but I also
place a "hook" in the PIC application code such that it can detect a special serial
sequence (from the PC loader) and do a "soft reset" to invoke the bootloader and
automatically begin the loading process. Avoids need for self programming code in
the PIC application code, also saves pressing a reset button or cycling the power
(my pet dislike is anything slowing down the code/program/test development cycle).
Also useful when using say a FTDI USB/serial chip that takes time for Windows to
detect and load when the device is plugged in (significantly longer than the time the
bootloader waits).
> For this chip, the boot code writes 128 bytes of new ROM data into the
> PIC's internal write buffer and then the write procedure is initiated.
Larger block/page/row size than PIC16F's, though it appears that may be variable.
Also from PIC18F47K40 data sheet: "CPU operation is suspended during a long
write cycle and resumes when the operation is complete."... that sounds like a good
thing too. It might be feasbile to duplicate some functions of the bootloader and
locate them in separate blocks... bootloader detects when it's about to erase/write
one block and so excutes from the other, ensuring predictable bootloader behaviour
when overwriting itself.
> Once the write process has completed, the PIC just continues on as
> normal and executes whatever code is at the current PC, whether it was
> changed by the write process or not.
I like the fact that PIC has instruction & data in a single word. It seems to make it
somewhat more robust in the rare occasion things do go wrong, like if the
bootloader process is interrupted for some reason and you end up with a mix of new
& old code... code fails to operate as expected, but in my experience not as haywire
as might be expected, with bootloader remaining operational and a simple reload
fixes it.
> I don't know if this approach will work for all PICs though, but here
> the entire ROM space can be reprogrammed.
I think that's probably the case for PIC16F's as well. It is of course in some cases
possible and at some times desireable to write protect the bootloader sector making
it impossible to change.
> My boot loader code is in a small block of its own ROM space that
> doesn't move with code modifications. Even so,, as I mentioned you
> have to be mindful of changes that will affect the execution of the
> boot loader programming loop.
>
> cheers
>
> Tony
>
>
>
> On Fri, Jan 12, 2018 at 8:02 AM, Brent Brown <***@eds.co.nz> wrote:
> > Interesting. Bootloaders normally(?) ignore/reject any commands to write within the address range they occupy. You could allow it to do so, but surely problems occur as soon as you alter the instruction about to be executed to something different. I can't see how you could get away with it unless every important piece of code in the bootloader that pertains to bootloading remains unchanged, and typically that would be all of it~!
> > I'm thinking mostly PIC16F here. Not sure if any PICs allow executing from RAM... if so that would be a different story.
> >
> >
> >
> >
> > -------- Original message --------
> > From: Anthony Nixon <***@gmail.com>
> > Date: 1/12/18 9:30 AM (GMT+12:00)
> > To: "Microcontroller discussion list - Public." <***@mit.edu>
> > Subject: [PIC] Boot Code Overwrite
> >
> > Hi all,
> >
> > I had a problem recently where a project is in use by some clients but
> > I had to rewrite the boot loader to make a new feature available.
> >
> > In the past I have had to write some temporary boot code to rewrite
> > the entire chip including the new boot code.
> >
> > It never occurred to me that a boot loader can rewrite over the top of
> > itself. To save myself a lot of code fuss, I tried this approach and
> > it works fine.
> >
> > The only caveat is that the new boot code must not modify (or very
> > carefully modify) any of the code target addresses that reside inside
> > the operating part of the boot code.
> >
> > Probably old news to some, but it saved me a lot of work.
> >
> > cheers
> >
> > Tony
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist