Searching \ for '[EE] [PIC] Powering another chip via IO line works' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/power.htm?key=power
Search entire site for: '[PIC] Powering another chip via IO line works'.

Exact match. Not showing close matches.
PICList Thread
'[EE] [PIC] Powering another chip via IO line works'
2007\02\21@170646 by Peter Todd

picon face
I have a circuit with a PIC chip, 12f683, and a DS32khz. I just finished
assembling the pcb's with parts on them, uploaded the tested and working
firmware and... it wasn't working.

The circuit runs off of a 3V lithium battery and to save power I had the
idea of running the DS32khz off of GP4 on the pic. So it'd normally
drive that IO line low, and when activated, drive it high. I figured
power can't be an issue, the DS32khz isn't supposed to consume more than
something like 1ma worst case, normally it's only using 2.5uA.

Breadboarded the circuit worked fine. But assembled the PIC would fail
to bring GP4 high, instead I got 0V. Disconnect the DS32khz and the pin
operates correctly. What I found fixed the problem was to remove the
0.1uF decoupling cap between GP4 and ground. I'm pretty sure my
breadboaded version didn't have that decoupling cap. Unfortunately I
didn't have time (or spare ds32khz chips) to investigate further, for
instance to see if adding a some series resistance would fix things.

Anyone else seen anything similar?

--
http://www.petertodd.ca

2007\02\21@172157 by Bob Barr

flavicon
face
On Wed, 21 Feb 2007 17:06:40 -0500, Peter Todd wrote:

<snip>
>
>Breadboarded the circuit worked fine. But assembled the PIC would fail
>to bring GP4 high, instead I got 0V. Disconnect the DS32khz and the pin
>operates correctly. What I found fixed the problem was to remove the
>0.1uF decoupling cap between GP4 and ground. I'm pretty sure my
>breadboaded version didn't have that decoupling cap. Unfortunately I
>didn't have time (or spare ds32khz chips) to investigate further, for
>instance to see if adding a some series resistance would fix things.
>
>Anyone else seen anything similar?
>

Could you possibly have a read-modify-write problem with the software?
That 0.1 uF cap will take a bit of time to charge. Any bcf/bsf
executed on the port  while it's charging will read back a zero and
clear the bit.


Regards, Bob

2007\02\21@172200 by Herbert Graf

flavicon
face
On Wed, 2007-02-21 at 17:06 -0500, Peter Todd wrote:
> I have a circuit with a PIC chip, 12f683, and a DS32khz. I just finished
> assembling the pcb's with parts on them, uploaded the tested and working
> firmware and... it wasn't working.
>
> The circuit runs off of a 3V lithium battery and to save power I had the
> idea of running the DS32khz off of GP4 on the pic. So it'd normally
> drive that IO line low, and when activated, drive it high. I figured
> power can't be an issue, the DS32khz isn't supposed to consume more than
> something like 1ma worst case, normally it's only using 2.5uA.

Stupid question, but did you check the ensure you have that pin in
digital mode?

TTYL

2007\02\21@172519 by Marcel duchamp

picon face
Peter Todd wrote:
> I have a circuit with a PIC chip, 12f683, and a DS32khz. I just finished
> assembling the pcb's with parts on them, uploaded the tested and working
> firmware and... it wasn't working.
>
> The circuit runs off of a 3V lithium battery and to save power I had the
> idea of running the DS32khz off of GP4 on the pic. So it'd normally
> drive that IO line low, and when activated, drive it high. I figured
> power can't be an issue, the DS32khz isn't supposed to consume more than
> something like 1ma worst case, normally it's only using 2.5uA.
>
> Breadboarded the circuit worked fine. But assembled the PIC would fail
> to bring GP4 high, instead I got 0V. Disconnect the DS32khz and the pin
> operates correctly. What I found fixed the problem was to remove the
> 0.1uF decoupling cap between GP4 and ground. I'm pretty sure my
> breadboaded version didn't have that decoupling cap. Unfortunately I
> didn't have time (or spare ds32khz chips) to investigate further, for
> instance to see if adding a some series resistance would fix things.
>
> Anyone else seen anything similar?
>
It sounds a lot like a read-modify-write problem.

2007\02\21@173046 by peter green

flavicon
face
> Breadboarded the circuit worked fine. But assembled the PIC would fail
> to bring GP4 high, instead I got 0V. Disconnect the DS32khz and the pin
> operates correctly. What I found fixed the problem was to remove the
> 0.1uF decoupling cap between GP4 and ground. I'm pretty sure my
> breadboaded version didn't have that decoupling cap. Unfortunately I
> didn't have time (or spare ds32khz chips) to investigate further, for
> instance to see if adding a some series resistance would fix things.
have you checked for read-modify-write issues on the pic port that you are using?

i'm thinking there may be some code that only ends up running when the DS232khz is in place (because removing the chip will have an affect on any logic lines that go to it) that does a rmw before the capacitor has charged to the point that the pic reads it as a logic high.



2007\02\21@173132 by PAUL James

picon face
Isn't GP3 reset pin?  If so, you would need to turn it off before you
can use it as an I/O.
If you can't turn it off and have the reset done internally, then it
won't work as an output pin.
Of course, I'm sure you've already thought of this, but just in case you
haven't.


                                                               Regards,

                                                                  Jim


{Original Message removed}

2007\02\21@173512 by Peter Todd

picon face
On Wed, Feb 21, 2007 at 02:21:51PM -0800, Bob Barr wrote:
> On Wed, 21 Feb 2007 17:06:40 -0500, Peter Todd wrote:
>
> <snip>
> >
> >Breadboarded the circuit worked fine. But assembled the PIC would fail
> >to bring GP4 high, instead I got 0V. Disconnect the DS32khz and the pin
> >operates correctly. What I found fixed the problem was to remove the
> >0.1uF decoupling cap between GP4 and ground. I'm pretty sure my
> >breadboaded version didn't have that decoupling cap. Unfortunately I
> >didn't have time (or spare ds32khz chips) to investigate further, for
> >instance to see if adding a some series resistance would fix things.
> >
> >Anyone else seen anything similar?
> >
>
> Could you possibly have a read-modify-write problem with the software?
> That 0.1 uF cap will take a bit of time to charge. Any bcf/bsf
> executed on the port  while it's charging will read back a zero and
> clear the bit.

Ahh... As in, the bit of code a few lines later, that's pwming the LED
with bsf GPIO,GP0, bcf GPIO,GP0

Yup, think you guys nailed that one... Yet another gotcha that I've read
about, but completely failed to make the connection when I actually ran
into it.


The circuit seems to work fine, and I've done a lot of testing on it.
Any reason to change it now? We're on a tight schedule and I'm supposed
to be sealing them up in less than an hour... Just wondering if this
sort of problem can happen intermittently.

--
http://www.petertodd.ca

2007\02\21@180515 by Wouter van Ooijen

face picon face
> Ahh... As in, the bit of code a few lines later, that's pwming the LED
> with bsf GPIO,GP0, bcf GPIO,GP0

Repeat N times after me: never ever do a bcf/bsf (or another RWM) on a
PIC12/14 port register.

Footnote in much smaller print: unless you realy realy know what you are
doing.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2007\02\21@201018 by Bob Axtell

face picon face
Wouter van Ooijen wrote:
>> Ahh... As in, the bit of code a few lines later, that's pwming the LED
>> with bsf GPIO,GP0, bcf GPIO,GP0
>>    
>
> Repeat N times after me: never ever do a bcf/bsf (or another RWM) on a
> PIC12/14 port register.
>
> Footnote in much smaller print: unless you realy realy know what you are
> doing.
>
>  
Use a mirror register. I use a pin on a PIC16F87 w/ 100nF to drive
another PIC12F629. Works
fine but MUST use the brownout detector, otherwise the startup is too
slow and the F629 is unreliable.

--Bob

2007\02\21@211552 by Jinx

face picon face
> Just wondering if this sort of problem can happen intermittently

If the problem is diagnosed and treated properly it should be OK.
You can (should) add a margin to make sure anyway. eg if the
chip takes 1ms to stabilise, give it 5ms. I do that when op-amps
and LCDs etc are powered from I/O and haven't had any trouble.
You could pare it to the bone but unless it's critical, a few ms extra
is neither here nor there

2007\02\21@223007 by Rikard Bosnjakovic

picon face
On 2/22/07, Wouter van Ooijen <spam_OUTwouterTakeThisOuTspamvoti.nl> wrote:

> Repeat N times after me: never ever do a bcf/bsf (or another RWM) on a
> PIC12/14 port register.

Why is that bad?

--
- Rikard.

2007\02\21@224320 by James Nick Sears

flavicon
face
Awhile back, hoping to spare people the frustration I experienced  
with these issues before fully understanding what was occurring, I  
wrote a description of this issue here: http://www.jamesnsears.com/
2006/10/read_modify_write_errors_why_t_1.php

In the past I have worked around this just by writing a little loop.  
Something like:

       bsf PORTA,0 ; set the bit

testlp:
       btfss PORTA,0
       goto testlp ; loop until it reads high

       delay ; then wait a little more for good measure (in case of a brief  
damped oscillation, etc)

I put this in a macro and used it all over the place when I was  
having the exact same issue, for the exact same reason (driving  
external ICs with bypass caps directly from pins).

Another thing I sometimes do is just leave PORTA,0 high all the time  
and toggle the TRISA,0 bit  (1 turns the pin off, 0 turns it on).  If  
you have something that can't float, like an external IC, this works  
fine.  I use this all the time when I write many-channel software PWM  
routines and the like.

-n.


On Feb 21, 2007, at 5:25 PM, Marcel duchamp wrote:

{Quote hidden}

> --

2007\02\22@003013 by Jinx

face picon face
> > Repeat N times after me: never ever do a bcf/bsf (or another RWM)
> > on a PIC12/14 port register.

> Why is that bad?

What James Nick Sears said

http://www.jamesnsears.com/2006/10/read_modify_write_errors_why_t_1.php

and

http://www.piclist.com/techref/readmodwrite.htm

http://www.sxlist.com/techref/scenix/sxrmw.htm

and Section 9.10.2 of

http://ww1.microchip.com/downloads/en/DeviceDoc/31009a.pdf

Basically the problem on is a component being driven not reacting
as fast as your software. The solution is software delays or software
shadow registers. PICs with Latch registers do not have this problem
because they have separate input (PORT) and output (LAT) registers

2007\02\22@021928 by Wouter van Ooijen

face picon face
> > Repeat N times after me: never ever do a bcf/bsf (or
> another RWM) on a
> > PIC12/14 port register.
>
> Why is that bad?

I suggest you either study the RMW problem (google, or read
http://www.voti.nl/swp ), or stay away from (at least these types of)
PICs!

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


More... (looser matching)
- Last day of these posts
- In 2007 , 2008 only
- Today
- New search...