16F88 locks up on the multiprogrammer board

[Peter]

I have had a problem with the multiprogrammer board apparently “locking up” PIC16F88s, so that PPP cannot identify, erase or program them. At first I thought that this was the same problem that is discussed in the FAQ, but the circumstances were not quite the same (it makes no difference whether RC or Xtal is selected on the programmer) and the FAQ's recommended way of unlocking the chips does not work.

I've managed to isolate the problem to the external oscillator for timer 1 on the 16F88. If I enable this from software the mutliprogrammer can no longer access the chip. I don't know why (maybe something to do with RB6 and 7?) but it is not a big problem for my project – I can manage with an internal clock for timer1.

But... do you have any advice on how I might reprogram the half-dozen or so PICs that I locked up while trying to track down this problem? PPP cannot access them.

[Benj]

Hello Peter

You may want to check your chip configuration settings. If you have turned on a thing called code protect then the chips will become non-programmable. This setting is only available using the expert setting of PPP so if you have not touched this setting then this is unlikely the case.

Is PPP able to autodetect the chip at all? If not then can PPP autodetect the USB board? Also any specific error messages you are getting would be helpful to track down the cause of your problem.

[Peter]

Hello Ben,

Thanks for the reply. I think I have solved the problem now (though I still don't know the cause).

I haven't switched on code protect - config fuse settings are:
#pragma DATA 0x2007, 0x3f38
#pragma DATA 0x2008, 0x3ffc
(I'm using Boost C on MPLAB to produce the hex files)

PPP simply reported that it could not identify the chip. Attempts to erase the chip failed ("erase failed"), and attempts to write new fuses just brought up the "cannot identify the chip" dialogue. Writing a new program also brought up that dialogue, then say that the chip was not erased, and then failed verification, referring to config1.

I have been doing some further tests and I can confirm the suspicion I mentioned in my earlier post - the problem only arises if my code enables the external oscillator of Timer 1 (by setting T1CON:T1OSCEN). This resolves the code problem for me because I don't really need that facility, but it might indicate an undocumented feature of the multiprogrammer board.

I have also just now found a way of unlocking those locked-up chips - I use PPPs repeat erase facility and pulse the reset button while this is happening. Seems to work reliably.

Thanks again for your reply,

Cheers,

[Benj]

Hello Peter

Thanks for the workaround glad your chips are up and running again, always annoying to have chips die on you. It definitely seems a little strange to be having such a impact. RB6 and RB7 are used for the external timer1 inputs and they seem to have a resonator circuit that is switched in similar to the main clock circuit. These pins are also used for device programming so this explains what you are experiencing.

Is your power supply providing the system with 12V or a higher voltage? Could be that with the timer module enabled the programming voltage doesn't quite reach the programming threshold. That's me just guessing now though.

Another guess would be something like you have to really slow down the programming speed with this option enabled, something that PPP is unable to do. You would think there would be a note somewhere in the datasheet though if this was an issue.

Would be nice to get this one resolved so I will have a bit of a dig and see if I can make this work.

[Peter]

Hi Ben,

My power supply is 13.5 volts, so I'm guessing that is not the problem?

I notice from Microchip's data sheet that when Timer 1 oscillator is enabled it overrides trisb and sets RB6 and 7 to inputs - so I'm guessing it also overrides their use for programming. The main problem with my program was that it enabled the oscillator as one of the first actions after start-up so as soon as power was applied the chip became none-programmable. That's what gave me the idea of pulsing the reset during multiple-erase - to try to allow it to see an erase signal before those pis were hi-jacked by the program.

Good luck with your digging around - I'd be interested to hear what you find out.

Cheers,

Peter

[Benj]

Hello Peter

I've managed to dig out a bit more information about this problem if you are interested. Seems even the Microchip PICkit2 has problems if the external timer1 input clock is enabled.

http://www.microchip.com/forums/tm.aspx?m=406538

[Peter]

Hi Ben,

Thanks for that link - very interesting, and I'm relieved that I'm not the only one having problems.

Cheers,

Peter