My circuit consists of a 12V battery (giving off 13V according to my
meter) connected to a 7805. The 7805 has a 35uF capacitor from ground
to output. The multimeter says the output voltage is 4.98V. This 5V
supply is connect to a 12F629 which has LEDs on pins 2 & 4 and a DC
operated piezo on pin 5 (the LEDs and piezo are just for debugging -
I'll try to do something useful when this works!). pins 0, 1 & 3 are
configured as inputs. Pin 0 is tied to -ve, 1 & 3 are unconnected. All
this is wired on a breadboard.
My problem is that the chip doesn't always seem to start - it's
programmed to give a short burst on the piezo at boot. The thing that
makes it start when it doesn't want to is me placing my finger above
the chip (sometimes I need to actually touch the plastic case of the
PIC). Even once booted nothing much works but one problem at a time :-)
Having a look on the web I find the piclist page re floating inputs
with the line:
"Some of these chips froze just by placing a finger near them, some
won't start, some start but run 'funny'."
Seems to be my problem however all the internal pull-up resistors
should be enabled - WPU is 0x37, OPTION_REG is 0x7F - so all inputs
(apart from GP0) should read as 1 if I have understood correctly.
>-----Original Message-----
>From: spam_OUTpiclist-bouncesTakeThisOuTmit.edu [.....piclist-bouncesKILLspam@spam@mit.edu]
>Sent: 22 August 2005 09:56
>To: piclistKILLspammit.edu
>Subject: [PIC] finger triggered circuit
>
>
>Hi,
>
>This is my first PIC project so be gentle! :-)
>
>My circuit consists of a 12V battery (giving off 13V according to my
>meter) connected to a 7805. The 7805 has a 35uF capacitor from ground
>to output. The multimeter says the output voltage is 4.98V. This 5V
>supply is connect to a 12F629 which has LEDs on pins 2 & 4 and a DC
>operated piezo on pin 5 (the LEDs and piezo are just for debugging -
>I'll try to do something useful when this works!). pins 0, 1 & 3 are
>configured as inputs. Pin 0 is tied to -ve, 1 & 3 are unconnected. All
>this is wired on a breadboard.
>
>My problem is that the chip doesn't always seem to start - it's
>programmed to give a short burst on the piezo at boot. The thing that
>makes it start when it doesn't want to is me placing my finger above
>the chip (sometimes I need to actually touch the plastic case of the
>PIC). Even once booted nothing much works but one problem at a time :-)
>
>Having a look on the web I find the piclist page re floating inputs
>with the line:
>
>"Some of these chips froze just by placing a finger near them, some
>won't start, some start but run 'funny'."
>
>Seems to be my problem however all the internal pull-up resistors
>should be enabled - WPU is 0x37, OPTION_REG is 0x7F - so all inputs
>(apart from GP0) should read as 1 if I have understood correctly.
>
>Any suggestions?
What are your configuration fuse settings? Specifically, do you have Pin4 set as MCLR or GP3?
Also note that an LED on pin 4 isn't going to help you much, this is the MCLR/GP3 line and it's an input only.
Regards
Mike
=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
> Also note that an LED on pin 4 isn't going to help you much, this is
> the MCLR/GP3 line and it's an input only.
Sorry when I said pin 1, 2 etc I meant GP1, GP2 etc. There is nothing
connected to GP3.
GP0 is tied to -ve and configured as an input.
GP1 is unconnected and configured as an input.
GP2 is connected to a LED and configured as an output.
GP3 is unconnected and configured as an input.
GP4 is connected to a LED and configured as an output.
GP5 is connected to a piezo and configured as an output.
On 22/08/2005, at 10:12 AM, Wouter van Ooijen wrote:
> Did you enable internal reset? If so maybe don't do that for a first
> project.
I left it on its default setting which is internal it seems. I'll
configure it for external and see if it helps.
> To rule out any static problems you could simple connect all pins to
> ground or +5V with a suitable resistor, I would take something like
> 100k
> or 220k.
I just quickly tried connecting GP1 and GP3 (the 2 unconnected inputs)
to ground via a 9.1K resistor (which is all I have at hand) and it
didn't help (in fact it doesn't seem to start even with the help of a
finger). Tonight I'll try the reset setting above and removing all the
actuators bar one LED, and making everything else and input tied to
ground.
>-----Original Message-----
>From: .....piclist-bouncesKILLspam.....mit.edu [EraseMEpiclist-bouncesspam_OUTTakeThisOuTmit.edu]
>Sent: 22 August 2005 10:27
>To: Microcontroller discussion list - Public.
>Subject: Re: [PIC] finger triggered circuit
>
>
>
>On 22/08/2005, at 10:03 AM, Michael Rigby-Jones wrote:
>
>> What are your configuration fuse settings? Specifically, do you have
>> Pin4 set as MCLR or GP3?
>
>_INTRC_OSC_NOCLKOUT & _WDT_OFF & _PWRTE_ON & _CP_OFF
>
>> Also note that an LED on pin 4 isn't going to help you much, this is
>> the MCLR/GP3 line and it's an input only.
>
>Sorry when I said pin 1, 2 etc I meant GP1, GP2 etc. There is nothing
>connected to GP3.
>
>GP0 is tied to -ve and configured as an input.
>GP1 is unconnected and configured as an input.
>GP2 is connected to a LED and configured as an output.
>GP3 is unconnected and configured as an input.
>GP4 is connected to a LED and configured as an output.
>GP5 is connected to a piezo and configured as an output.
>
>All internal pullups should be enabled.
>
>Sorry for the confusion,
No problem, it looks like you have pin 4 configured as the MCLR (reset) pin. This means you absolutely need a pullup to Vdd. The consequences of not having a pullup are exactly as you describe, i.e. flaky, intermittant operation, affected by bringing a finger near.
If you want to use GP3 as an input, you need to add '& _MCLRE_OFF' to you config line, though I find it's handy to have an external reset pin during the debugging stage so you don't have to cycle the power to reset the micro.
Regards
Mike
=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
Andrew wrote:
> My problem is that the chip doesn't always seem to start - it's
> programmed to give a short burst on the piezo at boot. The thing that
> makes it start when it doesn't want to is me placing my finger above
> the chip (sometimes I need to actually touch the plastic case of the
> PIC).
First suspect is that you have the MCLR pin enabled for the MCLR function
and it's not tied anywhere. If you are using it in the MCLR role, tie it to
Vdd via 20K ohms or so.
Second suspect is that LVP is enabled and the PGM pin is floating. Either
disable LVP or make sure PGM is tied low.
What is the oscillator mode? It's a good idea to start with internal RC
until you know the rest of the circuit is working.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
Wouter van Ooijen wrote:
> wow, LVP on an 8-pin PIC :)
Why do you say that? Does this PIC not have LVP? I haven't checked.
Floating PGM pin is just a stock answer for a problem like the OP described,
as is floating MCLR, and oscillator problems.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
> Wouter van Ooijen wrote:
> > wow, LVP on an 8-pin PIC :)
>
> Why do you say that? Does this PIC not have LVP? I haven't checked.
because the OP talked about an 12F629
> Floating PGM pin is just a stock answer for a problem like
> the OP described, as is floating MCLR, and oscillator problems.
Indeed. In this case floating MCLR is probably bulls eye, osc problems
seem less likely given the symptoms but is still a good thing to check,
and floating PGM is nonsense on a 12F629.
Which should not be taken as me flogging you for your answer, as long as
you don't flog me for my follow-up :)
Wouter van Ooijen
-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu
Switch the watchdog timer off if you haven't allready. It causes havoc
if you don't know how to handle it and why should you have it on if
you don't need it anyway? I presume that that's what Wouter meant when
he spoke of the 'internal reset'.
No. Internal reset means using internal MCLR and thus free
up one pin (input only). For example, Pin 4 of 12F629 is
GP3/Vpp//MCLR. It can be configured as the /MCLR pin or
an input only pin GP3. This is the same for all the new
8/14/20 pin PICs.
By the way, it is a good practice to enable Watchdog timer.
> By the way, it is a good practice to enable Watchdog timer.
I agree. But I must also admit that I, as a 'beginner', have other
things to worry about like getting the algorithms that are on paper
into the pic in perfect working order etc etc. WDT can definately wait
till my coding skills have improved beyond the point of me having to
worry about why that one little miserable thing doesn't quite do what
it should, or do you beg to differ?
Ooops, Olin. You need to check. It is quite obvious to me
that you have never worked with 12F629/675/...
They are quite unique MCUs.
Regards,
Xiaofan
Some of my observation with using the 12F629 for one year:
1. sharebank in the linker script
SHAREBANK NAME=gpr0nobnk START=0x20 END=0x5F
SHAREBANK NAME=gpr0nobnk START=0xA0 END=0xDF
2) They also need special header (with debug chip) to be used with ICD2.
3) Factory calibrated OSCCAL data is stored in 0x3FF. Programmers need to be
aware of this.
4) when using internal MCLR, there are some problems with ICD2 programming.
Wouter has a very good understanding of this and please refer to the
previous posts.
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.
Click OK to continue programming or click Cancel to cancel the programming
operation.
Work-Around
When External MCLR is used, this is not a problem, as Vpp can go directly to
Vihh. Also, if External Oscillator is used, the external oscillator can be
kept from running, thus keeping the code from running, until Vpp is at Vihh.
Wouter van Ooijen wrote:
> wow, LVP on an 8-pin PIC :)
Why do you say that? Does this PIC not have LVP? I haven't checked.
Floating PGM pin is just a stock answer for a problem like the OP described,
as is floating MCLR, and oscillator problems.
On 22/08/2005, at 10:40 AM, Michael Rigby-Jones wrote:
> No problem, it looks like you have pin 4 configured as the MCLR
> (reset) pin. This means you absolutely need a pullup to Vdd. The
> consequences of not having a pullup are exactly as you describe, i.e.
> flaky, intermittant operation, affected by bringing a finger near.
That was exactly the problem. I misread the data sheet and thought
reset was internal by default. Tieing this pin to +ve or adding
_MCLRE_OFF to my _config line fixed my booting problem.
Thanks to everyone for their help - I'm sure I would have been staring
at it for a long time without it.
I have just got everything working on my breadboard and thought I'd
share with you the things that took me longest to work out, for the
benefit of the archives or for the benefit of anyone thinking of
writing a book for newbies :-)
1) The external/internal reset issue that was the subject of this thread
2) The analogue comparator is on by default and must be switched off
before GP0 and GP1 are available
3) Most instructions don't seem to work with a "special" register as
their target e.g. andwf CMCON, F doesn't affect CMCON (at least in the
MPLAB sim)
You have to do your bit manipulation in W and then movwf the completed
value to the register in question. Incidentally thats how I assumed it
would have to be done before I read the data sheet. Something in the
data sheet (what I'm no longer sure) that gave me the impression I
didn't need to do it that way. I remember thinking it was pretty cool
you could use any register.
Yes programming with ICD2 is okay in normal cases (without internal
MCLR). With internal MCLR and internal RC OSC, programming with
ICD2 becomes a problem as well (ICDWarn0033). That is why I am
using PICkit 1 to program my 12F629. Okay I have a PM3 by my side
as well from yesterday. :)
I guess you are now better than a beginner and you can already
deal with WDT. I am not an expert in PIC software development
myself. My longest code is less than 2k words. Still I always
turn on WDT just to capture coding errors and for EMC reasons.
It is good practice to turn off WDT during debugging. After
debugging, to turn on WDT is not so difficult anyway.
Strictly speaking, we do not need a socket adaptor. :) All the new
PIC MCUs support ICSP. Still I do not consider ICD2 a very good
programmer since it has quite some problems with ICSP. But it
is the only game in town for dsPICs in its price range.
Regards,
Xiaofan
-----Original Message-----
From: William "Chops" Westfield [KILLspamwestfwKILLspammac.com]
Sent: Tuesday, August 23, 2005 9:11 AM
To: Microcontroller discussion list - Public.
Subject: Re: [PIC] finger triggered circuit
Only for debugging, right? You should be able to program them
with just the appropriate socket adaptor?
On Tue, Aug 23, 2005 at 02:36:11AM +0100, Andrew wrote:
> 3) Most instructions don't seem to work with a "special" register as
> their target e.g. andwf CMCON, F doesn't affect CMCON (at least in the
> MPLAB sim)
Are you sure? Did you have the bank bits set correctly?
Those instructions certainly should, and do IME, work with any register.
> On Tue, Aug 23, 2005 at 02:36:11AM +0100, Andrew wrote:
>> 3) Most instructions don't seem to work with a "special" register as
>> their target e.g. andwf CMCON, F doesn't affect CMCON (at least in the
>> MPLAB sim)
>
> Are you sure? Did you have the bank bits set correctly?
I had a banksel CMCON just before it. I had the same thing with a few
other registers. I'll double check to be sure later today. This was
only with the simulator - I didn't try it on the hardware when it
didn't work in the simulator.
> Those instructions certainly should, and do IME, work with any
> register.
I'll give it another test tonight in the simulator and make sure it
wasn't just me doing something stupid (again :-))
Chen Xiao Fan wrote:
> Ooops, Olin. You need to check. It is quite obvious to me
> that you have never worked with 12F629/675/...
No, actually I've done a bunch of projects with them and 16F630 which is the
same as the 12F629 with more pins. It's just that I do so many PIC projects
and there are so many PICs out there that after a while I don't remember the
details of each PIC off the top of my head.
For real projects of course I spend the extra minute to look up a detail
when I need it. But for answering PIClist questions for free, I don't
usually go that far, especially when listing a few general things to try.
> 2) They also need special header (with debug chip) to be used with ICD2.
These are such simple chips I've never wanted more than the simulator for
debugging.
> 3) Factory calibrated OSCCAL data is stored in 0x3FF. Programmers need
> to be aware of this.
Yes, both the EasyProg and ProProg are aware of the calibration value. It
is read before bulk erase, written to standard output for reference, and
restored during programming.
> 4) when using internal MCLR, there are some problems with ICD2
> programming. Wouter has a very good understanding of this and please
> refer to the previous posts.
I admit I've never attempted to program one of these with an ICD2. I've got
rather a large number of programmers floating around that can be made to
program the chip automatically from a build script if I want. There is no
reason to put up with the annoying clickety-click interface of the ICD2 for
programming.
> 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.
According to the programming spec DS41191C, page 4, figure 2.2, Vpp should
be raised to the programming voltage before Vdd, probably to avoid this very
problem. This is what my programmers do, and I can't imagine why the ICD2
can't do the same thing in programming mode, at least in the case where it
is controlling Vdd as described above. Duh!
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
Andrew wrote:
> 2) The analogue comparator is on by default and must be switched off
> before GP0 and GP1 are available
This is true of all PIC analog inputs. The standard PORT module of my PIC
development environment (http://www.embedinc.com/pic) together with the
/INBIT and /OUTBIT preprocessor directives automatically take care of this
so I never get caught by this issue.
> 3) Most instructions don't seem to work with a "special" register as
> their target e.g. andwf CMCON, F doesn't affect CMCON (at least in the
> MPLAB sim)
No, they definitely work. You probably don't have the bank bits set right.
For a good way of dealing with banking, see the DBANKIF and related macros
in STD.INS.DSPIC at the web page listed above.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
>-----Original Message-----
>From: RemoveMEpiclist-bouncesTakeThisOuTmit.edu [spamBeGonepiclist-bouncesspamBeGonemit.edu]
>Sent: 23 August 2005 02:36
>To: Microcontroller discussion list - Public.
>Subject: Re: [PIC] finger triggered circuit
>
>
>
>3) Most instructions don't seem to work with a "special" register as
>their target e.g. andwf CMCON, F doesn't affect CMCON (at least in the
>MPLAB sim)
> You have to do your bit manipulation in W and then
>movwf the completed
>value to the register in question. Incidentally thats how I assumed it
>would have to be done before I read the data sheet. Something in the
>data sheet (what I'm no longer sure) that gave me the impression I
>didn't need to do it that way. I remember thinking it was pretty cool
>you could use any register.
Hmm, that sounds odd. If you specifiy F as the destination that's where the result should go. Note that some bits in some registers may be "read only" so writing to them does nothing. The beauty of the PICs architecture is that SFR's and GPR's can be treated in exactly the same way (in most cases).
Regards
Mike
=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
> I admit I've never attempted to program one of these with an ICD2. I've got
> rather a large number of programmers floating around that can be made to
> program the chip automatically from a build script if I want. There is no
> reason to put up with the annoying clickety-click interface of the ICD2 for
> programming.
For the ones who are not so lucky, AutoIt3 may do the trick. This is a
scripting language that allows scripting of Windows GUI applications with
reasonable ease. With this, you can add a command line interface to most
GUI-only applications.
I just tried it (integrated Norton Ghost backups into my maintenance
script), and it's really easy to use.
>> For the ones who are not so lucky, AutoIt3 may do the trick. This is a
>> scripting language that allows scripting of Windows GUI applications
>> with reasonable ease. With this, you can add a command line interface
>> to most GUI-only applications.
> I agree. Thanks to someone here on the PIClist (perhaps it was you,
> Gerhard?)
Possibly, but not probably. AutoIt3 has been on my plate to try for a
while, but I just recently got around to actually use it -- with a push by
the absence of a command line interface in the new Ghost. (Who's
interested: http://tinyurl.com/bl8s6)
For using MPLAB's programmer I had used PowerPro scripts so far -- but
that's only useful if you use PowerPro anyway. AutoIt3 is much better for
this type of task, and much easier to get started too. I'll probably write
something like a command line driver for MPLAB over the next weeks.
> WinActivate("MPLAB IDE v7.10")
Maybe use WinActivate("MPLAB IDE *") -- you don't need to touch your script
just because you update MPLAB (if nothing relevant in the menus and
shortcuts has changed).
> Send("{F5}") ; ...in case the debugger is running - this doesn't always work,
> Sleep(500) ; as pressing F5 manually doesn't always halt the debugger.
Is there something in the window texts that comes up or goes away when the
debugger stops? (I don't use the debugger...)
>>> WinActivate("MPLAB IDE v7.10")
>>Maybe use WinActivate("MPLAB IDE *")
> Thanks. I'll make that change.
Not so quickly... :) That didn't work out so well.
The first thing that was wrong is the asterisk. On reading the help, it
does partial matching by setting opt( "WinTitleMatchMode", 2 ), not by
using asterisks or something. I thought I saw this somewhere in the
examples, but I was probably wrong.
>>> Send("{F5}") ; ...in case the debugger is running - this doesn't always work,
>>> Sleep(500) ; as pressing F5 manually doesn't always halt the debugger.
>
>> Is there something in the window texts that comes up or goes away when the
>> debugger stops? (I don't use the debugger...)
>
> I meant the ICD2 when I referred to the debugger. The output form
> displays "Removing Breakpoint" when the debugger is running. I could
> update the AutoIT code to look for that text - if it exists, then send
> F5 to halt, and then wait for "Halting Target" before continuing.
Exactly. It can take some time to find the proper unique conditions... a
standardized way to retrieve application states would be /really/ nice :)
spam_OUTembedinc.com [@spam@olin_piclistKILLspam
