Inchworm and MPLAB help please!!

[mramos1]

The inchworm works fine as ISP and ICD2.. But if you flipped on the internal oscilator, I know on some chips, you are hosed without a regular programmer to reset the register..

 

[Nigel Goodwin]

Any programmer that doesn't switch Vdd will have problems if MCLR isn't allocated to be a reset pin - as the only way it can stop the oscillator is by reseting the PIC, then selecting programming mode before the oscillator can start. So no reset pin, no reset possible from an ICD2.

 

[spondootre]

So is that a fundamental rule that I should stick to, to always have an external reset (MCLR) circuit and not set the configuration bit for internal? Or should this not be an issue if I now only use the inchworm?

 

[William At MyBlueRoom]

The inchworm works fine as ISP and ICD2.. But if you flipped on the internal oscilator, I know on some chips, you are hosed without a regular programmer to reset the register..

Which chips? The inchworm can reset, hold at VDD or pull high the MCLR pin. It should be able to reset any PIC that it can program (unlike the JDM style programmers). To use the debugger you pretty much have to not use internal MCLR in your design. If you MUST have every possible I/O pin then look at the ICD2 + header versions of the chip on digikey. It's a version of the chip that has the debug pins as well as all the normal I/O pins.
https://ww1.microchip.com/downloads/en/DeviceDoc/ICD2_Header_51292L.pdf

 

[kchriste]

So is that a fundamental rule that I should stick to, to always have an external reset (MCLR) circuit and not set the configuration bit for internal? Or should this not be an issue if I now only use the inchworm?

The only time you can safely set the external reset pin to general IO is if you have an external oscillator which you can stop by grounding the OSC1/CLKIN pin. With the ICD2, I have had luck reprogramming a PIC set for internal osc AND mclr as IO but it was hit and miss. It worked after a few tries.

 

[William At MyBlueRoom]

I'll have to try it. Which PIC seemed to do this? The 16F628A?

 

[mramos1]

Odd, I have a 16F88 that I flipped MCLR to input and turned on INT_OSC a few weeks ago, sat it aside for later to fix..

After reading this thread, I thought I would get out the P16PRO40, set the
config, wrote it no problem with an empty buffer. It said successful.

I went back to the ICD2 and still can not program it. I thought that would have fixed it as in the past I have done it with the ICD2 by hitting retry over and over with VERY small program and once using the P16PRO40 as well. When it did not work on the ICD2 I put it back in the P16PRO40 and it will not program via a larger .hex file.

Maybe I killed the pic, but I have done this other time and it worked.

I know for me, rule of thumb, leave MCLR alone and put that pullup on it. Since that, life has been good.

 

[William At MyBlueRoom]

Yep it can make the PIC non reprogrammable. Here's the warning right from MPLAB.

ICDWarn0033: You have selected Internal MCLR and Internal Oscillator in your configuration settings. If your code makes use of port pins that correspond to Clock and Data pins in programming mode, you may not be able to reprogram your device. See on-line help for this warning for more information. (OK/Cancel)
When Internal MCLR is used with MPLAB ICD 2 for programming, both Vpp and Vdd are powered together, and then Vpp is pulled high to Vihh to enter programming mode. This means that your code will be running before Vpp goes to Vihh. If that code makes use of port pins that correspond to Clock and Data pins in programming mode, there is a chance their values may not be 0, as necessary to enter programming mode. Therefore, the device could not be reprogrammed.

 

[mramos1]

Yep it can make the PIC non reprogrammable. Here's the warning right from MPLAB.

ICDWarn0033: You have selected Internal MCLR and Internal Oscillator in your configuration settings. If your code makes use of port pins that correspond to Clock and Data pins in programming mode, you may not be able to reprogram your device. See on-line help for this warning for more information. (OK/Cancel)
When Internal MCLR is used with MPLAB ICD 2 for programming, both Vpp and Vdd are powered together, and then Vpp is pulled high to Vihh to enter programming mode. This means that your code will be running before Vpp goes to Vihh. If that code makes use of port pins that correspond to Clock and Data pins in programming mode, there is a chance their values may not be 0, as necessary to enter programming mode. Therefore, the device could not be reprogrammed.

So I have a pic I can write a REAL small program too.. Will blink an LED with it one day ..

I thought the P16PRO40 would allow me to clear that config, but it did not.

And I really like the 16F88.. Will order more.

It was the first one I used too

Thanks for the info Bill..

 

[kchriste]

I'll have to try it. Which PIC seemed to do this? The 16F628A?

It was a 12F675 and IOs were at a premium!

 

[Nigel Goodwin]

I thought the P16PRO40 would allow me to clear that config, but it did not.

It will, as it switches Vdd it can program a PIC with internal oscillator and internal MCLR - my tutorials are all written using those settings.

What software were you using?.

 

[Odin]

When Internal MCLR is used with MPLAB ICD 2 for programming, both Vpp and Vdd are powered together, and then Vpp is pulled high to Vihh to enter programming mode. This means that your code will be running before Vpp goes to Vihh. If that code makes use of port pins that correspond to Clock and Data pins in programming mode, there is a chance their values may not be 0, as necessary to enter programming mode. Therefore, the device could not be reprogrammed.

I had to try this for myself, as I was pretty sure ICD2 works with or without
MCLR enabled. I've now tested it on 16F684 and 16F688. I'm using a ICD2 built from scratch on a veroboard, based on the schematics found on Lothar Stolz' webpage. MPlab ver. 7.50 I've written a small testprogram that toggles all pins at ca 2 Hz. There's no problem to program and reprogram, no matter if I set the fuse for MCLR to ON or OFF. With the fuse to OFF, the outputs toggle all the time. With ON, it can be controlled from Mplab.

Here's my config line for the 684:
__CONFIG _CP_OFF & _CPD_OFF & _BOD_OFF & _PWRTE_ON & _WDT_OFF & _INTRC_OSC_NOCLKOUT & _MCLRE_OFF & _FCMEN_OFF & _IESO_OFF

I don't claim that this will work in all cases, with all processors. But at least it works for me in this test, even with PGD and PGC used as outputs.

The Inchworm looks great btw! If I hadn't built my own already, I would surely have ordered one from you. I'd liked to have a USB version though. Think I saw something about it on your webpage? Based on a 18Fxxx? I guess it would be much faster, at least for debugging. Programming is fast enough already.
Odin

 

[mramos1]

It will, as it switches Vdd it can program a PIC with internal oscillator and internal MCLR - my tutorials are all written using those settings.

What software were you using?.

Winpic and Winpicprog. I will try it again. It is all still hooked up.

 

[Nigel Goodwin]

Winpic and Winpicprog. I will try it again. It is all still hooked up.

Check the Vpp delay setting on the hardware window, it needs to be small! - it's the delay time between applying Vdd and Vpp - Vpp must be applied before the internal oscillator can start running.