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, b= ut I also=20 place a "hook" in the PIC application code such that it can detect a specia= l serial=20 sequence (from the PC loader) and do a "soft reset" to invoke the bootloade= r and=20 automatically begin the loading process. Avoids need for self programming c= ode in=20 the PIC application code, also saves pressing a reset button or cycling the= power=20 (my pet dislike is anything slowing down the code/program/test development = cycle).=20 Also useful when using say a FTDI USB/serial chip that takes time for Windo= ws to=20 detect and load when the device is plugged in (significantly longer than th= e time the=20 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 var= iable.=20 Also from PIC18F47K40 data sheet: "CPU operation is suspended during a long= =20 write cycle and resumes when the operation is complete."... that sounds lik= e a good=20 thing too. It might be feasbile to duplicate some functions of the bootload= er and=20 locate them in separate blocks... bootloader detects when it's about to era= se/write=20 one block and so excutes from the other, ensuring predictable bootloader be= haviour=20 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=20 somewhat more robust in the rare occasion things do go wrong, like if the=20 bootloader process is interrupted for some reason and you end up with a mix= of new=20 & old code... code fails to operate as expected, but in my experience not a= s haywire=20 as might be expected, with bootloader remaining operational and a simple re= load=20 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 s= ome cases=20 possible and at some times desireable to write protect the bootloader secto= r making=20 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 >=20 > Tony >=20 >=20 >=20 > On Fri, Jan 12, 2018 at 8:02 AM, Brent Brown wrote: > > Interesting. Bootloaders normally(?) ignore/reject any commands to writ= e within the address range they occupy. You could allow it to do so, but su= rely problems occur as soon as you alter the instruction about to be execut= ed to something different. I can't see how you could get away with it unles= s every important piece of code in the bootloader that pertains to bootload= ing remains unchanged, and typically that would be all of it~! > > I'm thinking mostly PIC16F here. Not sure if any PICs allow executing f= rom RAM... if so that would be a different story. > > > > > > > > > > -------- Original message -------- > > From: Anthony Nixon > > Date: 1/12/18 9:30 AM (GMT+12:00) > > To: "Microcontroller discussion list - Public." > > 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 --=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 .