View previous topic :: View next topic |
Author |
Message |
vemir
Joined: 06 Jan 2014 Posts: 3 Location: Serbia
|
PIC12F675 /MCLR external reset problem |
Posted: Mon Jan 06, 2014 12:54 pm |
|
|
Hello. This is my first post and it is related to PIC12F765 reset problem.
What looked like a simple problem, turned out to be a huge fuss.
I'm using CCS v. 4.093 with MPLAB IDE v8.83.
I'm trying to reset PIC externally, with reset circuit comprising of resistor and pushbutton arranged so that when button is pressed voltage on /MCLR pin is pulled down (to 0V). External oscillator is used (10MHZ).
I've connected one LED diode and accompanying resistor as a signalization for when PIC is in reset (when I press and hold reset button I expect LED to turn off because PIC is in reset). Then, I set #FUSES MCLR in code.
When I press button however, nothing happens. LED light stays on.
Could someone clarify what is going on here? Why there is no reset?
Here is my code:
Code: |
#include <12F675.h>
#fuses HS
#use delay(clock=10000000)
#fuses NOWDT //No Watchdog Timer
#fuses NOBROWNOUT //No Brownout Detection
#fuses MCLR // druga opcija je NOMCLR - No Master Clear Reset.
#fuses PUT //Power Up Timer
#fuses NOPROTECT //Code not protected from reading
#fuses NOCPD //No EE protection
#define GP0 PIN_A0
#define GP1 PIN_A1
#define GP2 PIN_A2
#define GP3 PIN_A3
#define GP4 PIN_A4
#define GP5 PIN_A5
void main(void)
{
set_tris_a(0b11110110); //inputs and outputs
while(1)
{
output_high(GP1); // LED on
}//while
}//main |
|
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9250 Location: Greensville,Ontario
|
|
Posted: Mon Jan 06, 2014 2:34 pm |
|
|
hmm... My first thought was the setting of pin A1 to an input in the set_tris(..) function.Normally you let the compiler handle the tris registers cause if you misconfigure them, you're in trouble. I'd remove that line since you're not using 'fast_io'.
Then I thought, well the ADC is attached to that pin by default and you don't have a 'no-analog' statement..but...that shouldn't leave the LED on.
Then I considered the 'weak-pullup' option, but that is supposed to be turned off when a pin is an output.Although you have set_tris(...) wrong, the compiler will(should) add correct code for the output_high(..) statement.
That leads me to the compler version. 4.093 might be 'young' and have a few bugs though something like this is pretty simple.
Query? Have you done the '1Hz flashing LED 'program to confirm the PIC circuit is wired correctly? It could easily be a silly wiring error!
Please let us know what happens...
hth
jay |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19559
|
|
Posted: Mon Jan 06, 2014 2:48 pm |
|
|
MPLAB......
By default, MPLAB compiles for 'DEBUG' operation.
This turns off the MCLR pin.
You need to change the settings in MPLAB, to compile for release.
It is doubly annoying in this case, since DEBUG can't be used without the debug header, but MPLAB still makes this change....
Best Wishes |
|
|
vemir
Joined: 06 Jan 2014 Posts: 3 Location: Serbia
|
|
Posted: Mon Jan 06, 2014 3:19 pm |
|
|
Thank you for your ideas.
It was MPLAB catch all this time!
I changed settings in: Project/Build configuration/Release
and LEDs turned off magically as I pressed pushbutton.
Hooray! |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9250 Location: Greensville,Ontario
|
|
Posted: Mon Jan 06, 2014 3:34 pm |
|
|
yeah.. that will do it as well.
About MPLAB V8.6ish, uChip allowed for the user to default the 'build configuration' to either 'debug' or 'release'. I'd called them about it as 8.5 was always 'debug', you had to manually change it,recompile EVERY time...tech gave me a 'patch' and said they'd change it next upgrade, which they did.
I never use 'debug' prefer to test in the real world where the PICs have to perform as no 'simulator' can catch a lOT of real world 'issues'.
Glad it's up and running !
jay |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
|
vemir
Joined: 06 Jan 2014 Posts: 3 Location: Serbia
|
|
Posted: Wed Jan 08, 2014 2:45 pm |
|
|
Thanks Jay, PCM Programmer and Ttelmah.
Best Wishes
Stefan |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9250 Location: Greensville,Ontario
|
|
Posted: Wed Jan 08, 2014 3:46 pm |
|
|
The patch shouldn't be needed after 8.65. I know 8.86 doesn't need it. I'd assume anyone using MPLAB should be running something a lot newer than 8.65!
jay |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Wed Jan 08, 2014 4:08 pm |
|
|
I disagree. I tested it just now with MPLAB vs. 8.91 and the registry
patch is necessary. Here is how I tested it:
1. I already had the registry patch installed, so I clicked on Start / Run
and typed regedit (this is in XP) and ran it. I then went to the location
for the DefaultBuildConfiguration string value and deleted it. I closed regedit.
2. I started MPLAB vs. 8.91 and went to the Project / Project Wizard menu
and made a new project, with folder for it, and when done, the drop-down
box said "Debug". I then closed MPLAB.
3. I ran regedit again and following the instructions in the patch link,
I created the DefaultBuildConfiguration string value and set it to Release.
I then closed regedit.
4. I started MPLAB vs. 8.91 again, and made another new project with
a different name, in its own folder, and I closed the Project Wizard.
This time, the drop-down box said "Release".
Conclusion: the patch is still necessary, as least as of MPLAB vs. 8.91.
Note: This whole discussion is only about MPLAB vs. 8.xx, not MPLAB-X. |
|
|
gpsmikey
Joined: 16 Nov 2010 Posts: 588 Location: Kirkland, WA
|
|
Posted: Wed Jan 08, 2014 5:11 pm |
|
|
Something to consider on your reset circuit - push buttons tend to bounce. Just having a resistor and no cap in the circuit leaves you with the option of multiple resets when you push the button that may or may not confuse things (or will bite you later when you use a different button that bounces more/longer). _________________ mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3 |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9250 Location: Greensville,Ontario
|
|
Posted: Wed Jan 08, 2014 6:07 pm |
|
|
hmm. Have to admit I never tested the debug/release with a 'virgin' version of MPLAB. Since it worked when I upgraded to v8.86, I'd assumed the software guys at uchip had done whatever needed to be done in MPAB to allow the 'default' value of the build configuration to be either 'debug' or 'release'. I spent an hour on the phone with him and he said it would be added to the next version >v8.63.
As I'm one who 'leaves well enough alone if it works', it never occoured to me that the internal patch hadn't been done. Microchip mentality was/is that everyone uses 'debug' first, then recompiles in 'release' mode. I spent half my time explaining that I cut code, burn the PIC, test in the real world. I could see the blank look over then phone....sigh...
Maybe the patch should become a 'sticky'? Along with why programs don't work in the 'real world' if compiled in 'debug' mode?
jay |
|
|
|