Post by thread:[PIC] Strange behavior of PICmicro I/O pin

Hello Everyone, EXPERIMENT 1 I have a 16F676 @ 4MHz communicating with 24LC256 using RC1 (SDA, with 1K pull up) and RC2 (SCL). I am using bit bang technique. As observed on an oscilloscope, the SDA and SCL lines raise to 5V and fall to 1V but not to 0V. I removed the 24LC256 thinking it could be pulling the line high. Again, as observed on an oscilloscope, the SDA and SCL lines raise to 5V and fall to 1V (above TTL level) but not to 0V. I started single stepping the code. Now the SDA and SCL both raise to 5V and fall to 0V. I inserted some 10 uS delay between SDA and SCL lines changing the state. Still no success. EXPERIMENT 2 Removed the 24LC256. Ran the below code. bsf portc,scl bsf portc,sda goto $+1 bcf portc,scl bcf portc,sda goto $-5 Same results. If I run this with 5 mS delay then the I/O lines reach 0v. I am unable to understand this behavior. Has anyone come across this type of behavior? Cheers Ravi

Ravi, It might be better if you include all of the code you are running. You do not show any of the setup here. Have you set RC1/2 as digital pins? At power up, these pins will be configured for digital inputs. Either try clearing the relevant bits in ANSEL, or use RC4/5 Also, make sure that you have cleared the relevant bits in TRISC to set the pins as outputs. Matt On 9 July 2010 12:59, Ravi <spam_OUTchiptechTakeThisOuTvsnl.com> wrote: {Quote hidden}> > Hello Everyone, > > EXPERIMENT 1 > > I have a 16F676 @ 4MHz communicating with 24LC256 using RC1 (SDA, with > 1K pull up) and RC2 (SCL). > > I am using bit bang technique. > > As observed on an oscilloscope, the SDA and SCL lines raise to 5V and > fall to 1V but not to 0V. > > I removed the 24LC256 thinking it could be pulling the line high. > > Again, as observed on an oscilloscope, the SDA and SCL lines raise to 5V > and fall to 1V (above TTL level) but not to 0V. > > I started single stepping the code. Now the SDA and SCL both raise to 5V > and fall to 0V. > > I inserted some 10 uS delay between SDA and SCL lines changing the > state. Still no success. > > EXPERIMENT 2 > > Removed the 24LC256. > > Ran the below code. > > bsf portc,scl > bsf portc,sda > goto $+1 > bcf portc,scl > bcf portc,sda > goto $-5 > > Same results. > > If I run this with 5 mS delay then the I/O lines reach 0v. > > I am unable to understand this behavior. > > Has anyone come across this type of behavior? > > Cheers > > Ravi >

Matt, > It might be better if you include all of the code you are running. You > do not show any of the setup here. Have you set RC1/2 as digital pins? Yes, in ANSEL. > At power up, these pins will be configured for digital inputs. > Either try clearing the relevant bits in ANSEL, or use RC4/5 > Also, make sure that you have cleared the relevant bits in TRISC to > set the pins as outputs. Yes. I have mentioned tha the o/p toggles between +5V and 0V at low frequency but at higher frequencies, it does not reach 0V but reaches only 1V. Regards Ravi {Quote hidden}> > Matt > > On 9 July 2010 12:59, Ravi <.....chiptechKILLspam@spam@vsnl.com> wrote: > > > > Hello Everyone, > > > > EXPERIMENT 1 > > > > I have a 16F676 @ 4MHz communicating with 24LC256 using RC1 > (SDA, with > > 1K pull up) and RC2 (SCL). > > > > I am using bit bang technique. > > > > As observed on an oscilloscope, the SDA and SCL lines raise to > 5V and > > fall to 1V but not to 0V. > > > > I removed the 24LC256 thinking it could be pulling the line high. > > > > Again, as observed on an oscilloscope, the SDA and SCL lines > raise to 5V > > and fall to 1V (above TTL level) but not to 0V. > > > > I started single stepping the code. Now the SDA and SCL both > raise to 5V > > and fall to 0V. > > > > I inserted some 10 uS delay between SDA and SCL lines changing the > > state. Still no success. > > > > EXPERIMENT 2 > > > > Removed the 24LC256. > > > > Ran the below code. > > > > bsf portc,scl > > bsf portc,sda > > goto $+1 > > bcf portc,scl > > bcf portc,sda > > goto $-5 > > > > Same results. > > > > If I run this with 5 mS delay then the I/O lines reach 0v. > > > > I am unable to understand this behavior. > > > > Has anyone come across this type of behavior? > > > > Cheers > > > > Ravi > > --

On 9 July 2010 14:55, <chiptechKILLspamvsnl.com> wrote: > Matt, > >> It might be better if you include all of the code you are running. You >> do not show any of the setup here. Have you set RC1/2 as digital pins? > > Yes, in ANSEL. > >> At power up, these pins will be configured for digital inputs. >> Either try clearing the relevant bits in ANSEL, or use RC4/5 >> Also, make sure that you have cleared the relevant bits in TRISC to >> set the pins as outputs. > > Yes. > > I have mentioned tha the o/p toggles between +5V and 0V at low frequency but at higher frequencies, it does not reach 0V but reaches only 1V. Have you tried using RC4/5, to elimitate any possible interference from the analogue circuitry on RC1/2? Matt

Oops, I guess the "goto $-5" would need to change. How about a label? On Thu, 08 Jul 2010 23:18:12 -0700, "Bob Blick" said: {Quote hidden}> Hi Ravi, > > Try putting nops in like this: > > bsf portc,scl > nop > bsf portc,sda > goto $+1 > bcf portc,scl > nop > bcf portc,sda > goto $-5 > > If it works then it is probably a read-write-modify issue, which occurs > when a pin hasn't changed enough before the next bcf or bsf happens. > > Cheerful regards, > > Bob > > -- > http://www.fastmail.fm - Access all of your messages and folders > wherever you are > > --

> bsf portc,scl > bsf portc,sda > goto $+1 > bcf portc,scl > bcf portc,sda > goto $-5 More than likely a read-modify-write issue http://www.piclist.com/techref/readmodwrite.htm As Bob suggests, separate the port bit instructions Here's an illustrated example of how a h/w problem can be caused by s/w that is too fast (especially on the PIC-like Scenix) http://www.sxlist.com/techref/scenix/sxrmw.htm

Em 9/7/2010 03:17, Matt Callow escreveu: > On 9 July 2010 14:55, <.....chiptechKILLspam.....vsnl.com> wrote: >> Matt, >> >>> It might be better if you include all of the code you are running. You >>> do not show any of the setup here. Have you set RC1/2 as digital pins? >> Yes, in ANSEL. >> >>> At power up, these pins will be configured for digital inputs. >>> Either try clearing the relevant bits in ANSEL, or use RC4/5 >>> Also, make sure that you have cleared the relevant bits in TRISC to >>> set the pins as outputs. >> Yes. >> >> I have mentioned tha the o/p toggles between +5V and 0V at low frequency but at higher frequencies, it does not reach 0V but reaches only 1V. > Have you tried using RC4/5, to elimitate any possible interference > from the analogue circuitry on RC1/2? > > Matt Analog mode on PIC pins only interfere with inputs, it doesn't matter if an output pin is configured as analog. Isaac __________________________________________________ Fale com seus amigos de graça com o novo Yahoo! Messenger http://br.messenger.yahoo.com/

> > I inserted some 10 uS delay between SDA and SCL lines changing the > state. Still no success. > Like everyone else has said, this is most likely a read-modify-write issue. Use a register as a "latch" like on the 18F series. As in: portclatch equ 0x?? bcf portclatch,scl bcf portclatch,sda movf portclatch,w movwf portc Use the register as you would PORTC in your code, but remember to move it to the actual PORTC after you're done making changes. > I have a 16F676 @ 4MHz communicating with 24LC256 using RC1 (SDA, with > 1K pull up) and RC2 (SCL). > Any reason for 1K? Do you need the speed? You can probably use a bigger resistor like 10K or 22K and not have to sink so much current when you pull the line down.

Bob, > Try putting nops in like this: > > bsf portc,scl > nop > bsf portc,sda > goto $+1 > bcf portc,scl > nop > bcf portc,sda > goto $-5 The original I2C code goes like this (a part of it). txbyte movlw .8 movwf bitctr btfss txbuf,7 goto $+3 bsf iicport,sda goto $+3 bcf iicport,sda goto $+1 goto $+1 bsf iicport,scl goto $+1 goto $+1 bcf iicport,scl rlf txbuf,same decfsz bitctr,same goto $-0Dh bsf iicport,scl bsf iicport,sda retlw 0 > If it works then it is probably a read-write-modify issue, which occurs > when a pin hasn't changed enough before the next bcf or bsf happens. This code would work for me on 16C54's years back. Cheers Ravi

Ivp, > More than likely a read-modify-write issue > > http://www.piclist.com/techref/readmodwrite.htm > > As Bob suggests, separate the port bit instructions > > Here's an illustrated example of how a h/w problem can be caused > by s/w that is too fast (especially on the PIC-like Scenix) > > http://www.sxlist.com/techref/scenix/sxrmw.htm It is separated and was working earlier on 16c54's. If I find a solution, I will post it. Cheers Ravi

At 08:21 AM 7/9/2010, you wrote: >Adam, > > > Any reason for 1K? Do you need the speed? You can probably use a > > bigger resistor like 10K or 22K and not have to sink so much current > > when you pull the line down. > >The SDA line connects tot he 24LC256 SEEPROM. The 1K pull up is >required. This used to work for me on other devices like 16C54, 16F870, etc. > >This is the first time I am using this on 16F676. You have set the relevant SCL/SDA port bits to 0 and are writing to the TRIS registers, not the port registers, to control SCL/SDA, right? >Best regards, Spehro Pefhany --"it's the network..." "The Journey is the reward" EraseMEspeffspam_OUTTakeThisOuTinterlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com

At 08:17 AM 7/9/2010, you wrote: Are you trying to modify someone else's code extracted from an existing PIC design? {Quote hidden}>The original I2C code goes like this (a part of it). > >txbyte movlw .8 > movwf bitctr > btfss txbuf,7 > goto $+3 > bsf iicport,sda > goto $+3 > bcf iicport,sda > goto $+1 > goto $+1 > bsf iicport,scl > goto $+1 > goto $+1 > bcf iicport,scl > rlf txbuf,same > decfsz bitctr,same > goto $-0Dh > bsf iicport,scl > bsf iicport,sda > retlw 0 > > > > If it works then it is probably a read-write-modify issue, which occurs > > when a pin hasn't changed enough before the next bcf or bsf happens. > >This code would work for me on 16C54's years back. > >Cheers > >Ravi >

Spehro, > You have set the relevant SCL/SDA port bits to 0 and are writing to the > TRIS registers, not the port registers, to control SCL/SDA, right? Below is my initialisation code. initialise clrf porta clrf portc bsf status,5 <------------ Bank 1 movlw b'10000000' movwf ansel movlw b'00110000' movwf adcon1 IF DEBUG movlw b'11111011' ELSE movlw b'11111000' ENDIF movwf trisa movlw b'11001011' movwf trisc movlw b'11010011' movwf option_reg clrf wpua clrf ioca bcf status,5 <--------- Bank 0 movlw b'00000111' movwf cmcon clrf t1con retlw 00h The same problem is happening in PORTA,2. Cheers Ravi

Em 9/7/2010 08:55, Adam Field escreveu: >> I inserted some 10 uS delay between SDA and SCL lines changing the >> >> state. Still no success. >> > Like everyone else has said, this is most likely a read-modify-write > issue. Use a register as a "latch" like on the 18F series. As in: It doesn't seem to be really a RMW problem. RMW will make a pin have the *wrong* state ( 1 or 0 ), but not an *undefined* state. The OP said that the pin stays at 1V for a long period (over 10us if I understood correctly). This is not '1' nor '0'. Things to check: 1) Is the pull-up really connected? Isn't it of a too low value? 2) Is the code really outputting a '0'? (check bank selection, perhaps TRISx is not being written). Isaac __________________________________________________ Fale com seus amigos de graça com o novo Yahoo! Messenger http://br.messenger.yahoo.com/

Isaac, > It doesn't seem to be really a RMW problem. RMW will make a pin have the > *wrong* state ( 1 or 0 ), but not an *undefined* state. > > The OP said that the pin stays at 1V for a long period (over 10us if I > understood correctly). This is not '1' nor '0'. > > Things to check: > > 1) Is the pull-up really connected? Isn't it of a too low value? 1K pull up on SDA (RC1) line and no pull up on SCL (RC2) line. This is being used for SEEPROM. > 2) Is the code really outputting a '0'? (check bank selection, perhaps > TRISx is not being written). I am checking on an oscilloscope. That's why i am able to see the voltage at 1V. If I increase the delay to about 1mS, then the voltage reaches 0. I had used this code as is in other PICmicro. Cheers Ravi

> -----Original Message----- > From: piclist-bouncesspam_OUTmit.edu [@spam@piclist-bouncesKILLspammit.edu] On Behalf > Of Ravi > Sent: 09 July 2010 13:46 > To: Microcontroller discussion list - Public. > Subject: Re: [PIC] Strange behavior of PICmicro I/O pin > > Spehro, > > > You have set the relevant SCL/SDA port bits to 0 and are writing to the > > TRIS registers, not the port registers, to control SCL/SDA, right? > > Below is my initialisation code. > > initialise clrf porta > clrf portc Spehro is not referring to your initialisation code, but the way in which you are manipulating the port pins when sending data/clock signals. I2C is an open collector bus system; when "bit bashing" an I2C master interface you set the output data latches low and leave them. You then set the TRIS bit to 0 to output a low state, and the TRIS bit to 1 to output a high state (the resistor pulls the pin up to Vdd). However, the fact that you see this issue with no EEPROM connected makes me think this is not the problem. What it does sound suspiciously like is your PIC does not have its Vss pin(s) grounded properly, and is instead grounding through one or more of the ESD protection diodes. This could certainly explain the voltage offset when the pin is low. 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. =======================================================================

Hello Everyone, I thank everyone for taking time out to guide me in my problem. My apologies to you all for troubling you. I used a different oscilloscope probe and found out that the signals are going towards 0V (less than 0.8V) with sharper edges. All these days the other probe was performing well. Now I have thrown it into the dustbin. At low frequencies, the probe was performing well. At higher frequencies the probe was misbehaving. Happy PICking. Ravi On 09/07/2010 7:05 PM, Michael Rigby-Jones wrote: > > >> {Original Message removed}

Em 9/7/2010 10:25, Ravi escreveu: {Quote hidden}> Isaac, > >> It doesn't seem to be really a RMW problem. RMW will make a pin have the >> *wrong* state ( 1 or 0 ), but not an *undefined* state. >> >> The OP said that the pin stays at 1V for a long period (over 10us if I >> understood correctly). This is not '1' nor '0'. >> >> Things to check: >> >> 1) Is the pull-up really connected? Isn't it of a too low value? > 1K pull up on SDA (RC1) line and no pull up on SCL (RC2) line. This is > being used for SEEPROM. > >> 2) Is the code really outputting a '0'? (check bank selection, perhaps >> TRISx is not being written). > I am checking on an oscilloscope. That's why i am able to see the > voltage at 1V. > > If I increase the delay to about 1mS, then the voltage reaches 0. > > I had used this code as is in other PICmicro. > > Cheers > > Ravi If you set the oscilloscope time base to some appropriated value, can you see the voltage on the pin falling from 1V to around 0V? Does this fall resemble a capacitor discharge curve? Does the voltage fall from 5V to 1V quickly (ns range), then the fall rate reduces around 1000 times? Do you have any additional components connected to the I2C signals? Can you rule out damage to the PIC or memory? Can you replace them to be sure none of them is damaged? The ground connection between both chips is good and low resistance? The scope probe ground is also connected to the PIC's ground in a good manner? Best regards, Isaac __________________________________________________ Fale com seus amigos de graça com o novo Yahoo! Messenger http://br.messenger.yahoo.com/

Ravi wrote: > I have a 16F676 @ 4MHz communicating with 24LC256 using RC1 (SDA, with > 1K pull up) and RC2 (SCL). I didn't look up a 24LC256, but from the signal names (SDA, SCL) you are apparently using IIC to communicate with it. If so, with a 1K ohm pullup you can't run the bus at more than 3V due to the 3mA max sink requirement of IIC nodes. Remember that ohms equals volts divided by amps, which tells you how to calculate the lowest allowed pullup resistor. If pulling up to 5V, this is 5V / 3mA = 1.7Kohms. I can't even guess how you came up with 1K ohms. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000.

Ravi wrote: > The SDA line connects tot he 24LC256 SEEPROM. The 1K pull up is > required. I find that hard to believe. Where exactly is this requirement stated? I'm thinking 80% chance you misunderstood something. Show us a reference to this spec. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000.

On 09/07/2010 22:34, Olin Lathrop wrote: > Ravi wrote: >> The SDA line connects tot he 24LC256 SEEPROM. The 1K pull up is >> required. > I find that hard to believe. Where exactly is this requirement stated? I'm > thinking 80% chance you misunderstood something. Show us a reference to > this spec. > > > ******************************************************************** > Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products > (978) 742-9014. Gold level PIC consultants since 2000. the 24LC256 works fine for me with 18F4550 and 16F877A using SW I2C and 4k7 for both pullups

Ravi wrote: > All these days the other probe was performing well. Now I have thrown > it into the dustbin. > > At low frequencies, the probe was performing well. At higher > frequencies the probe was misbehaving. I would take it back out of the "dustbin" and fix its compensation adjustment instead. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000.