12F1822 MCLR input problem

hobiadami · Joined: 17 Oct 2006 Posts: 35 Location: City of Concrete

Hello All,

I've searched the forum for the answer with no luck. On the net I've found some other posts from people who experience the same problem. But I didn't find the solution yet.

I'm using 5.012 version compiler on a pic 12f1822 for a project which was running fine on 12f675 and 683. The project uses the mclr pin as an input.

I've had difficulty using the mclr as input on 1822 cpu. So 'I've setup a simple led-switch circuit to test. It's the same, 12f683 works, 1822 doesn't.
The led is off, when the button is pressed, it turns on for a second. Then off again. On f683 it is ok. On 1822, the led is always on, it turns off as long as i press the button.

It is probably related to misconfiguration of the more complex features of 1822. But might also related to some bugs in the tools. So I'm here. :D

The circuit schematic and the code is in the image below:
https://www.dropbox.com/s/l1y6gnko8cbttz5/Screenshot%202017-05-09%2011.48.06.png?dl=0

The test circuit was sketched on Proteus but the test was done on a breadboard with actual hardware.

Ttelmah · Joined: 11 Mar 2010 Posts: 19539

Driving the LED without a resistor.

Overloading the PIC.....

Triggers a brownout reset.

hobiadami · Joined: 17 Oct 2006 Posts: 35 Location: City of Concrete

Thanks for the quick reply. Although it is missing at the schematic, there is a 470 ohm resistor in series with the led at the actual circuit. And brownout is also disabled on the fuses.

https://www.dropbox.com/s/dwv4gl58d73yi62/WIN_20170509_13_04_34_Pro.jpg?dl=0
_________________
www.endtas.com

Ttelmah · Joined: 11 Mar 2010 Posts: 19539

Doesn't help give us confidence when what is posted isn't what is being used...

Put a diode across the pull-up resistor. So the signal cannot go above Vdd. Even a momentary few mV above the supply, will switch the chip into programming mode.

hobiadami · Joined: 17 Oct 2006 Posts: 35 Location: City of Concrete

I've inserted a 5.1v zener cathode on the mclr pin, anode on ground to prevent higher voltages on mclr but it runs the same. But if i replace the controller with a 12f683 and use the code below (which is identical apart from two fuses), it works fine. Without any diode anything, the same board, the same power supply.

Ttelmah · Joined: 11 Mar 2010 Posts: 19539

Read the code back from the chip.
Check the config bytes.

It honestly sounds as if the MCLR is still enabled. Your programmer may not be turning it off correctly. How are you compiling the code?. Not possibly in MPLAB?. If so it enables DEBUG by default, which prevents MCLR from being disabled. The 675 for example, does not support DEBUG....

hobiadami · Joined: 17 Oct 2006 Posts: 35 Location: City of Concrete

Yes the issue is probably something like that. I've read the chip and my config word is 3FF8.

Compiling the code on ccs ide. Not using mplab.

I'm using CCS device programmer 5.041 and an ICD-64 (Rev 1 PID:193)
with firmware version 3.21.

I've added a new fuse NODEBUG to code. Still the same thing happens.
_________________
www.endtas.com

Ttelmah · Joined: 11 Mar 2010 Posts: 19539

Are you disconnecting the pull up resistor when you program, or removing the chip from the board?.
If not, then the programmer probably can't program properly.

hobiadami · Joined: 17 Oct 2006 Posts: 35 Location: City of Concrete

To program I'm removing the chip from the board onto another breadboard with the programming and power pins attached to the chip from the ICD. Power is also supplied by the icd during programming with the 5v jumper on inside the ICD-64 box.
_________________
www.endtas.com

Ttelmah · Joined: 11 Mar 2010 Posts: 19539

Tell the programmer to do a full erase, then reprogram.
You may have the option to erase the config fuses turned off.

(and make sure the programmer is set to write the fuses). Tick box in the main screen.

jeremiah · Joined: 20 Jul 2010 Posts: 1354

It might not hurt to check the LST file at the bottom and see what the FUSES are actually being set to. You might be able to find a bug that way (if there is one). You might have to look at the hex values vs the data sheet to be sure.

hobiadami · Joined: 17 Oct 2006 Posts: 35 Location: City of Concrete

I'll try to erase the chip and recheck the config bits first thing in the morning. The fuses at the bottom of the LST file are

Configuration Fuses:
Word 1: 2984 INTRC_IO NOWDT PUT NOMCLR NOPROTECT NOCPD NOBROWNOUT NOCLKOUT NOIESO FCMEN
Word 2: 1EFF NOWRT PLL_SW STVREN BORV19 NODEBUG NOLVP

Ttelmah · Joined: 11 Mar 2010 Posts: 19539

You will notice these don't match what you read from the chip.
This is why I suspect the fuses are not either being erased or programmed....

hobiadami · Joined: 17 Oct 2006 Posts: 35 Location: City of Concrete

Can this mean i need a new ICD or something like pickit3 etc?

Ttelmah · Joined: 11 Mar 2010 Posts: 19539

I'd primarily suspect a setting.
In the options, you need to have the config bits box ticked. Also if you open this tab out (click on the top right corner), 'bulk erase chip before programming'. Otherwise some config bits can't be erased. Also the little 'Use LVP' box needs to either say 'auto', or no.
Other possibility is the latest firmware has a problem. I've had several versions that will not program specific chips, but not devices like this (the more modern devices).