I replied onlist but in a hurry and without adding the subject tag which=20 might be why you didn't see it - I'll copy and paste below : "Totally a stab in the dark but make sure you have adequate decoupling on=20 the microcontroller. I had issues with a product that had a 0.1uf decoupling cap a little too fa= r from the power pins of the controller for comfort - it would randomly reset and occasionally randomly accessed parts of the program it shouldn't. Needless to say, worth double checking as well as making sure any unused pins are set as outputs or any inputs are adequately pulled high or low and not left floating." Dom -----Original Message-----=20 From: John Coppens Sent: Thursday, February 13, 2014 5:42 PM To: piclist@mit.edu Subject: Re: [PIC] 18f2550 auto-erasing On Thu, 13 Feb 2014 08:59:31 -0800 Barry Gershenfeld wrote: > (Reposted with topic tag) > > * * > > A contradiction: > > >> Now, the program itself frequently _moves_ 32-byte > >> blocks from program memory to RAM, but > >> never writes in program memory. > > Versus: > > >> I normally use an USB bootloader to load the actual software. > > Maybe you'll see it as semantics, but "never writes to program memory" > isn't accurate. What you mean is that you don't do that intentionally. > But there is a routine present in memory at all times that will=20 > cheerfully > write to program memory if that routine is entered. I'm not trying to > split hairs. I remember a long discussion years ago here in which this > sort of thing was hashed out. You have actually run some good experiment= s > for us that pretty much points to the block erase function as the culprit= .. > Meaning, it's not some hardware glitch that causes blocks to disappear. > Instead, it's probably "random code execution". Hello Barry, Yes, I am aware of that, of course, and this was the reason to eliminate the bootloader from memory. The 'random code execution' does seem quite unrandom though. Just a couple of reboots is enough! Two different chip show same behaviour. > So, what to do? Everything Dom just said applies, and I won't repeat > that. Another level of protection might be to make it more difficult for > the bootloader code to write to program memory (like "secret unlock > codes"). But you can only be so clever, because there will always some > place you can jump to that knows all the tricks to do the erase. As well > as the core erase routine itself. I'm sorry I didn't receive whatever Dom wrote. I suspect Dom is replying indirectly from the PIClist (how/where?). I was thinking in inserting some control after the AA/55 sequence to put the memory in write mode. Bail out if not in correct bootload mode. The random execution has to pass the AA/55 sequence, unless there is a hardware quirk which randomly disables that protection too. > Microchip has some parts (don't recall--might be only the 32-bit) that > allow you to access the configuration once and only once at power on, the= n > protects it. This could allow the bootloader to access normally protecte= d > space. But that's not a guarantee if there are startup glitches. The 18F2550 lets you protect the config area optionally - you can re-enable config-writing on external programming only. But, as far as I can see, no useful combination would protect the chip from random execution and still enable bootloading. > There are situations where there's a cause and then there are subsequent > preventions to guard against the actions of the cause. In my humble > opinion, it is best to prevent the problem in the first place, than to tr= y > deflecting it later. I think attacking possible startup glitches and=20 > power > problems is the way to do it. By the way, where I worked, we always used > an external brownout/reset controller (simple 3-pin device) and have neve= r > experienced this particular problem. And I did have a bootloader most > times. The default internal (hardware-only) brown-out protection was enabled during all this. But I have been suspecting why Microchip describes externa= l BO protection circuits if there is an internal, quite developed, protection circuit present. Thanks! John > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist --=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=20 --=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 .