On Thu, 13 Feb 2014 08:59:31 -0800 Barry Gershenfeld wrote: > (Reposted with topic tag) >=20 > * * >=20 > A contradiction: >=20 > >> Now, the program itself frequently _moves_ 32-byte > >> blocks from program memory to RAM, but > >> never writes in program memory. >=20 > Versus: >=20 > >> I normally use an USB bootloader to load the actual software. >=20 > 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 cheerful= ly > 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= =20 quirk which randomly disables that protection too. =20 > 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 pow= er > 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 =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 http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .