ICSP and oscillator

pommie I have to stay all i can see is trouble using pgd and pgc
It's like your saying

The Timer1 oscillator shares the T1OSI
and T1OSO pins with the PGD and PGC
pins used for programming and
debugging.
When using the Timer1 oscillator, In-Circuit
Serial Programming™ (ICSP™) may not
function correctly (high voltage or low
voltage), or the In-Circuit Debugger (ICD)
may not communicate with the controller.
As a result of using either ICSP or ICD
operation, the Timer1 crystal may be
damaged.
If ICSP or ICD operations are required, the
crystal should be disconnected from the
circuit (disconnect either lead), or installed
after programming. The oscillator loading
capacitors may remain in-circuit during
ICSP or ICD operation

Click to expand...

Pommie said:

Unfortunately, this will not work. As soon as you enable the timer1 oscillator the ICSP stops working even if no crystal is present.

Mike.

Click to expand...

Does that mean that enabling the timer1 oscillator is a one-time action? If the ICSP isn't working, can the device be erased?

Pommie said:

Unfortunately, this will not work. As soon as you enable the timer1 oscillator the ICSP stops working even if no crystal is present.

Mike.

Click to expand...

I don't think that is right, once MCLR is raised to Vpp all the PIC pins go high impedance and the PGC and PGD are enabled ready to program.

However that doesn't mean the xtal and resistors won't cause programming problems. If using a slower programmer it mght be ok but the new fast ones can be a bit fussy with loads on PGC and PGD.

Unfortunately, Microchip decided that unless they can confirm which chip is connected to a Pickit2 or ICD2 they would not even attempt to go into programming mode. So the only way to "fix" a chip that has timer1 oscillator enabled is to connect a good chip, let MPLAB recognize it, hot swap the chip for the "broken" one and immediately erase it.

One of the "inferior" programmers (JDM etc.) probably will erase them.

BTW, if you have a JuneBug this is very easy to confirm but don't try it unless you have a spare 1320 or a different programmer.

Mike.

I'm still not getting it Pommie.

To "confirm which PIC" before going into program mode... Doesn't that require raising MCLR to Vpp, then communicating with the PIC via PGC and PGD (ie by using the programming system) to find out what PIC it is??

And to know if TMR1 osc is enabled, doesn't that mean it has to read the CONFIG bits, which is also a Vpp task?

It is just as Pommie said.

The programmer does not ID the chip as part of the program operation. But it will not program unless it has ID'ed the chip. So you ID a good one, swap in a bad, and program.

3v0

I've only had this happen with the 16f88 and 18f1320 I set them for timer1 osc and wasn't no crystal there I just set it wrong and didn't see it till later. I tried every thing to erase them chips I gave up I then put a new chip in the bread board read it I still had the old chip in there to so I said let's swap chips and erased them and see what happens the chip worked fine.

Mr RB said:

I'm still not getting it Pommie.

To "confirm which PIC" before going into program mode... Doesn't that require raising MCLR to Vpp, then communicating with the PIC via PGC and PGD (ie by using the programming system) to find out what PIC it is??

And to know if TMR1 osc is enabled, doesn't that mean it has to read the CONFIG bits, which is also a Vpp task?

Click to expand...

The chip can be read without applying Vpp and this is what MPLAB tries to do. It fails to read it and assumes no chip is present and you are "messing about" when you ask it to erase a none existent chip.

To turn on Timer1 oscillator does not require a change to the config. You simply set bit 3 of T1CON.

Mike.

Pommie said:

The chip can be read without applying Vpp and this is what MPLAB tries to do.
...

Click to expand...

???. How does it read anything without being in Vpp mode? Are you talking about when it is in ICD mode?

This is sounding more and more like a specific bug with that programmer (and/or ICD) than anything to do with the PIC.

You only need to apply Vpp to program or erase. The problem arises because Microchip are cautious and don't apply the 12v required until they know that the chip can take it.

If you have any chips that share the ICSP pins with the timer1 oscillator then just try it. Take any code and insert bsf T1CON,T1OSCEN and you will discover it's true.

Mike.

What a trip! It even does it in my EasyPIC6 dev board that uses the MikroE PICFlash 2.1 formware as the USB programmer. Once I set T1CON.T1OSCEN it could not complete a Vpp read operation and then once it can't read the PIC it can't even read the ID numbers so (as you said) it can't ID the device type.

It's not a fault with the PIC, I just read the 18F1320 errata, and there are no issues mentioned in the 18F1320 programming PDF either. And my production programmer was able to do a sucessful read and full erase on the 18F1320 to "fix" it.

It's some weird bug with the PK2 (and obviously the MikroE PICFlash 2 conforms to that PK2 firmware functionality too).

How do you get around this porgrammer fault if you wanted to do an app with that PIC and TMR1 osc?? I'd just use one of my non-buggy programmers but I feel sorry for anyone who just relies on a PK2...

OK, I did some more testing and found the problem.

What is happening is that the PIC starts to run the code, THEN the T1OSCEN is set in the code, then that takes over the T1OSO/PGC line, so the programmer can't clock program data to do program read of the device ID or any other operation.

My EasyPIC6 has a plug-in xtal, so unplugging the xtal meant the PIC did not execute code and the T1OSCEN doesn't get set after a reset, and it can now be reprogrammed with no dramas.

If you are using the internal RC osc (like I do on my Junebug) then this is going to be a problem.

The root of the problem is that the PK2 programmer resets the PIC, then is sloppy and lets the PIC execute a few mS of code, then does another reset, and by that time the T1OSCEN has been set so programming (or reading device ID) can't happen.

I just tried another solution, I put a 3 second delay in the code so after reset it takes 3 seconds before T1OSCEN is set. Now even with the xtal in place I can manually reset it, then as long as I click "program" before the 3 seconds expires it will reprogram with no issues.

So if you are getting this programmer bug it can be worked around by;
1. stop the PIC clock (remove xtal etc)
2. put a couple seconds delay before turning T1OSCEN ON
3. use a button etc to turn T1OSCEN ON/OFF as needed
3. use any software system to turn T1OSCEN OFF before you want to program next time
4. get a better programmer

The strange thing is that Microchip can easily fix this in MPLAB but for some reason don't think it is a problem. The fix would not even require a change to the PK2 firmware as all that is required is a force erase command in MPLAB.

Mike.

I'm surprised they haven't jumped on it too... It's a crippling problem and it's with their own IDE and their own (most popular) programmer.

Just thinking aloud, a simple solution might be done via PK2CMD.EXE to force erase the target part. If someone comes up with it I'd be sure to add it to the Junebug manual.

I just tried everything I could think of but without success. However, I don't have the bs250 so can't do Vpp first programming. Maybe someone could try pk2cmd -PPIC18F1320 -E -X to see if it works. Pk2cmd is located in C:\Program Files\Microchip.

Mike.