It does sound like the issue is with the bootloader. I've been using tinybld with the 18F2550 for quite some time with no problems: http://www.etc.ugal.ro/cchiculita/software/picbootloader.htm John Hansen Coastal ChipWorks On Thu, Feb 13, 2014 at 8:20 AM, John Coppens wrote: > Hello all. > > A display I made for my wife's pharmacy uses an 18f2550 to control > everything. > When I installed it, everything was fine, but, for some reason, after a > couple > of days the display stopped working. I could repeat this 'reliably' at > home: > switching the display on/off a number of times caused a 'memory loss': > blocks > of memory were erased (seemingly 32 byte-blocks). The position of the > erased > blocks seems random. > > Now, the program itself frequently _moves_ 32-byte blocks from program > memory > to RAM, but never writes in program memory. Not sure if this could be > related. > > Is this device so sensitive to power outages? > > I considered/tried the following: > > 1) I normally use an USB bootloader to load the actual software. One time= a > block from the USB loader itself was erased, so I enable WRB (boot write > protect). That seemed to protect the loader. > > 2) Code protection was already enabled, but I reasoned that I could not > enable the program memory write protection, as the bootloader would then > not > be able to write new versions. > > 3) Finally I removed the bootloader, and put in a recompiled version, wit= h > all protections enabled. That seems to have solved it. Many tests at home= , > and now on site, and still no problems. > > Q: Is there no way to retain the actual bootloader and still have some > protection for those spurious writes? > > 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 .