CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

PIC12F675 /MCLR external reset problem

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
vemir



Joined: 06 Jan 2014
Posts: 3
Location: Serbia

View user's profile Send private message

PIC12F675 /MCLR external reset problem
PostPosted: Mon Jan 06, 2014 12:54 pm     Reply with quote

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. Smile

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: 9101
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Mon Jan 06, 2014 2:34 pm     Reply with quote

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: 19217

View user's profile Send private message

PostPosted: Mon Jan 06, 2014 2:48 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Mon Jan 06, 2014 3:19 pm     Reply with quote

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. Smile

Hooray! Smile
temtronic



Joined: 01 Jul 2010
Posts: 9101
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Mon Jan 06, 2014 3:34 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Mon Jan 06, 2014 5:11 pm     Reply with quote

Right, but you never post the patch. I always do that. Here it is:
http://www.ccsinfo.com/forum/viewtopic.php?t=46818&start=21
vemir



Joined: 06 Jan 2014
Posts: 3
Location: Serbia

View user's profile Send private message

PostPosted: Wed Jan 08, 2014 2:45 pm     Reply with quote

Thanks Jay, PCM Programmer and Ttelmah.

Best Wishes
Stefan
temtronic



Joined: 01 Jul 2010
Posts: 9101
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Wed Jan 08, 2014 3:46 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Wed Jan 08, 2014 4:08 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Wed Jan 08, 2014 5:11 pm     Reply with quote

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: 9101
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Wed Jan 08, 2014 6:07 pm     Reply with quote

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
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group