On Wed, Jun 23, 2004 at 12:47:29AM +0200, Kyrre Aalerud wrote: > I was planning on using a different approach actually. > Programming the flash would be a password-protected option in the regular > rs232 comm dialog. Cool. > There would not be a bootloader of such. The loader function will be at the > very last block of memory (small loader I > will write myself...) and the only thing that will be done is dump the > incoming data onto the program memory up to the point of the loader. But the two issues I raised are still in effect. The first is pretty easy to handle in your case, simply do not erase or rewrite the first row of memory. And just be aware that you need to erase the memory before you rewrite it. > > I realize now that this method could cause the program to be corrupted and > thus, I would not have any means of entering the loader again... No. Since your loader will control writing the memory, just set it up so that it won't overwrite itself. End of problem. The application may be blown away, but the loader is still intact to load again. > I would need a short loader init or something that would not be reprogrammed > so that I would have a way of entering rs232 programming at startup. Simply preserve the 1st row (which is the first 32 words IIRC). It'll stay intact except for the possible glitch where you application wanders into the weeds and somehow ends up in your loader accidentally. > I > guess waiting a timeout value for a character on the rs232 would be > suffichient... Maby as simple as the character F for "flash"... If it is > received upon powerup, go directly to the flash routine and ask for a > password before beginning flash programming. Only programming and > verifcation would be needed I think. No need to add advanced stuff like > crc's and stuff. Well I'd still throw in a simple checksum for communications verification. > > Hmm... Reset is at 0000 as usual and interrupt is at 0004. To have the > most effichient interrupt routine I would like to stay clear of that area. Make it a fixed jump to somewhere else that your application can take care of it. > It does seem however that I can protect the first memory page from ever > being written internally and that is the smallest block I can protect like > that. Let me check on the 16F88 having the protected boot block... It does. So that's another safer possibility. You can actually write the loader in the 1st page and be reasonably sure that it'll be safe. I really wish that the boot block were at the end and only the first row were protected. It would simplify the loading of generic applications. > It will allow me to reprogram the rest of the memory even with the > entire chip code protected, but I will have to select a new interrupt > vector. This means I will also have to include the context-saving in the > protected section to be sure I save the right data. Right. > > Hmm, this will be fun!!! I'd sure like to see the loader part when you're done. BAJ > > > Kyrre > > > ----- Original Message ----- > From: "Byron A Jeff" > To: > Sent: Tuesday, June 22, 2004 10:40 PM > Subject: Re: [PIC]: Self-programming via rs232 of the 16F88 ? > > > > On Tue, Jun 22, 2004 at 10:19:21PM +0200, Kyrre Aalerud wrote: > > > Hi people! Long time since I've posted... > > > > Well welcome back. > > > > > > > > I wanted to ask if someone had good/bad experiences on making the 16F88 > > > chips program themselves via a small bootloader subroutine and rs232... > > > > I haven't gotten there yet. It's on my growing list of things to do. > > > > > I > > > was going to use rs232 anyway in my circuit for configuration and > offloading > > > of statistical sensor-data, but then I found the chip can self-program! > > > > One of the multitude of goodies that it offers. Truly the 16F84 of the new > > millenium. > > > > > By > > > telling chip to reprogram memory, upgrading software would be possible > after > > > I mold the circuit into epoxy too! > > > > Absolutely. > > > > > (This circuit has to be waterproof and > > > very sturdy so molding it is a good and fast way to achieve that.) > > > > Care to tell us about a watertight connector? Just out of curiousity... > > > > > > > > Pipedream or possible ? > > > > Definitely doable. > > > > > Share your experiences please? > > > > > > > Any dogs burried in this approach ? > > > > The usual. You lose a bit of program memory. Also there will be some > startup > > delay because you have to have some interaction between the bootloader and > > the PC. One idle thought was if the box isn't always connected to RS232 > one > > could possibly have RxD pulled up to a break condition, with then a > connected > > TxD automagically pulling it down to idle when connected. The bootloader > could > > then have an extremely brief delay followed by a check of RxD before > > configuring serial port. If it's pulled high, then presume that nothing is > > connected to the serial port and proceed normally, otherwise activate the > > bootloader protocol. If the bootlloader responds, then proceed to load new > > program, otherwise presume you're connected to the application's target > serial > > and interact with it. A bit complicated, but if startup time is critical > then > > it could save a second or two in terms of timing out. > > > > > Anything I need to consider? > > > > I'm current playing with the Tiny bootloader: > > > > http://www.ac.ugal.ro/staff/ckiku/software/picbootloader.htm > > > > The web server is refusing requests but it's cached in Google. Check the > > archives for the thread "Need 16F819 bootloader" or somesuch. Extensive > > discussions of the issue there. Bottom line is that ordinary 16F87X > bootloaders > > won't work because 4 word writes are required and 16F87XA bootloaders > won't > > work because the 16F8X and 16F81X require row level erases to happen > before > > you can reprogram. Also in the thread another loader (name forgotten) > points > > out that when you erase the first row that you erase the jump to the > bootloader > > on reset so you have to restore it. Again check the threads for more info > on > > the subject. > > > > My plan is to update Tiny to load for the 16F88 and 16F819. But it may be > > a minute or two (or a month or two) before I get to it. > > > > BAJ > > > > -- > > http://www.piclist.com hint: The PICList is archived three different > > ways. See http://www.piclist.com/#archives for details. > > > > -- > http://www.piclist.com hint: The PICList is archived three different > ways. See http://www.piclist.com/#archives for details. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.