Strange problem: Setting an output low on PORTA, causes another output on PORTA to go low too. Below is the entire program. It should generate two signals: ---, ,---, ,---, ,---, ,--- '---' '---' '---' '---' -, ,---, ,---, ,---, ,--- '- -' '---' '---' '---' But instead gives this: -, ,-, ,-, ,-, ,- '-----' '-----' '-----' '-----' -, ,---, ,---, ,---, ,--- '- -' '---' '---' '---' If I generate the second signal on an output of PORTB, it all works okay. L0000: MOVLW 00 L0001: MOVWF 0A L0002: GOTO 004 L0003: NOP L0004: CLRF 04 L0005: MOVLW 1F L0006: ANDWF 03,F L0007: BSF 03,5 L0008: BCF 1F,4 L0009: BCF 1F,5 L000A: MOVF 1B,W L000B: ANDLW 80 L000C: IORLW 0F L000D: MOVWF 1B L000E: MOVLW 07 L000F: BCF 03,5 L0010: MOVWF 1F L0011: MOVLW 00 L0012: TRIS 5 L0013: NOP L0014: NOP L0015: NOP L0016: BSF 05,2 L0017: NOP L0018: NOP L0019: NOP L001A: BCF 05,3 L001B: NOP L001C: NOP L001D: NOP L001E: BCF 05,2 L001F: NOP L0020: NOP L0021: NOP L0022: BSF 05,3 L0023: GOTO 013 END Any suggestions? -- Thanks, Frank. (remove 'x' and 'invalid' when replying by email)
PIC16F88, PORTA strange behaviour
Started by ●December 2, 2004
Reply by ●December 2, 20042004-12-02
"Frank Bemelman" <f.bemelmanx@xs4all.invalid.nl> schreef in bericht news:41af158c$0$566$e4fe514c@news.xs4all.nl...> Strange problem: > > Setting an output low on PORTA, causes another output > on PORTA to go low too. > > Below is the entire program. It should generate two signals: > > ---, ,---, ,---, ,---, ,--- > '---' '---' '---' '---' > -, ,---, ,---, ,---, ,--- > '- -' '---' '---' '---' > > But instead gives this: > > -, ,-, ,-, ,-, ,- > '-----' '-----' '-----' '-----' > -, ,---, ,---, ,---, ,--- > '- -' '---' '---' '---' > > If I generate the second signal on an output of PORTB, > it all works okay. > > L0000: MOVLW 00 > L0001: MOVWF 0A > L0002: GOTO 004 > L0003: NOP > L0004: CLRF 04 > L0005: MOVLW 1F > L0006: ANDWF 03,F > L0007: BSF 03,5 > L0008: BCF 1F,4 > L0009: BCF 1F,5 > L000A: MOVF 1B,W > L000B: ANDLW 80 > L000C: IORLW 0F > L000D: MOVWF 1B > L000E: MOVLW 07 > L000F: BCF 03,5 > L0010: MOVWF 1F > L0011: MOVLW 00 > L0012: TRIS 5 > L0013: NOP > L0014: NOP > L0015: NOP > L0016: BSF 05,2 > L0017: NOP > L0018: NOP > L0019: NOP > L001A: BCF 05,3 > L001B: NOP > L001C: NOP > L001D: NOP > L001E: BCF 05,2 > L001F: NOP > L0020: NOP > L0021: NOP > L0022: BSF 05,3 > L0023: GOTO 013 > END > > Any suggestions?And also, when I change everything to use outputs on PORTB, everything also works as expected. Is there something seriously wrong with PIC16F88 ? -- Thanks, Frank. (remove 'x' and 'invalid' when replying by email)
Reply by ●December 2, 20042004-12-02
"Frank Bemelman" <f.bemelmanx@xs4all.invalid.nl> wrote in news:41af158c$0$566$e4fe514c@news.xs4all.nl:> Strange problem: > > Setting an output low on PORTA, causes another output > on PORTA to go low too. > > Below is the entire program. It should generate two signals: > > ---, ,---, ,---, ,---, ,--- > '---' '---' '---' '---' > -, ,---, ,---, ,---, ,--- > '- -' '---' '---' '---' > > But instead gives this: > > -, ,-, ,-, ,-, ,- > '-----' '-----' '-----' '-----' > -, ,---, ,---, ,---, ,--- > '- -' '---' '---' '---'Are you doing this without delays in the inter-port pin state changes? That is, fast? If so, you've hit the fun errate of read-modify-write on a port. Try using a pin on port A and a pin on another port, the problem should go away. Microchip has a good description of this problem in one of the PIC documents. I can't find it right now. It may have been in the Q&A section of the PIC18 reference. Good luck. -- - Mark -> --
Reply by ●December 2, 20042004-12-02
"Mark A. Odell" <odellmark@hotmail.com> schreef in bericht news:Xns95B35A85127CFCopyrightMarkOdell@130.133.1.4...> "Frank Bemelman" <f.bemelmanx@xs4all.invalid.nl> wrote in > news:41af158c$0$566$e4fe514c@news.xs4all.nl: > > > Strange problem: > > > > Setting an output low on PORTA, causes another output > > on PORTA to go low too. > > > > Below is the entire program. It should generate two signals: > > > > ---, ,---, ,---, ,---, ,--- > > '---' '---' '---' '---' > > -, ,---, ,---, ,---, ,--- > > '- -' '---' '---' '---' > > > > But instead gives this: > > > > -, ,-, ,-, ,-, ,- > > '-----' '-----' '-----' '-----' > > -, ,---, ,---, ,---, ,--- > > '- -' '---' '---' '---' > > Are you doing this without delays in the inter-port pin state changes? > That is, fast? If so, you've hit the fun errate of read-modify-write on a > port. Try using a pin on port A and a pin on another port, the problem > should go away. Microchip has a good description of this problem in one of > the PIC documents. I can't find it right now. It may have been in the Q&A > section of the PIC18 reference. Good luck.No, it's not that. When I pick two outputs on B there is no problem. With two outputs on A, presto. Also happens with milisecond delay in between. The code I included was just to demonstrate this behaviour. I really start thinking it's a flaw in the F88, on the other hand I can hardly believe that this has to be discovered on my workbench ;) I'll try a workaround, updating the entire port instead of single pins. -- Thanks, Frank. (remove 'x' and 'invalid' when replying by email)
Reply by ●December 2, 20042004-12-02
On Thu, 2 Dec 2004 15:23:17 +0100, "Frank Bemelman" <f.bemelmanx@xs4all.invalid.nl> wrote:>..Also happens with milisecond delay in >between. The code I included was just to demonstrate this behaviour..Whenever you use BCF and BSF instructions to set or clear bits on a port, the entire port is read and then written. If you have enough loading on the output that it reads back as something other than what you wrote (i.e. past the half-way point between the voltage supply rails) then the latch for the port will adopt the forced value. Try your test with absolutely no loading on the output. -Robert Scott Ypsilanti, Michigan (Reply through this forum, not by direct e-mail to me, as automatic reply address is fake.)
Reply by ●December 2, 20042004-12-02
>Subject: PIC16F88, PORTA strange behaviour >From: "Frank Bemelman" f.bemelmanx@xs4all.invalid.nl >Date: 02/12/2004 13:17 GMT Standard Time >Message-id: <41af158c$0$566$e4fe514c@news.xs4all.nl> > >Strange problem: > >Setting an output low on PORTA, causes another output >on PORTA to go low too. >>Below is the entire program. It should generate two signals: > >---, ,---, ,---, ,---, ,--- > '---' '---' '---' '---' >-, ,---, ,---, ,---, ,--- > '- -' '---' '---' '---' > >But instead gives this: > >-, ,-, ,-, ,-, ,- > '-----' '-----' '-----' '-----' >-, ,---, ,---, ,---, ,--- > '- -' '---' '---' '---' >your program looks like it should work, you should not use the tris instruction anymore though.I haven't checked the datasheet some pics use porta for ad conversion check that you have set the pins to digital. Your reading the port pins very soon after changing them if there is too much load its possible that theyy havent had time to settle.
Reply by ●December 2, 20042004-12-02
Frank Bemelman wrote:> "Mark A. Odell" <odellmark@hotmail.com> schreef in bericht >> Are you doing this without delays in the inter-port pin state >> changes? That is, fast? If so, you've hit the fun errate of >> read-modify-write on a port. Try using a pin on port A and a pin on >> another port, the problem should go away. Microchip has a good >> description of this problem in one of the PIC documents. I can't >> find it right now. It may have been in the Q&A section of the PIC18 >> reference. Good luck. > > No, it's not that. When I pick two outputs on B there is no problem. > With two outputs on A, presto. Also happens with milisecond delay in > between. The code I included was just to demonstrate this behaviour.It's probably to do with your initialization stuff on PORTA. I've never used the '88, so I'm not sure what you might be missing. Your ADCON0 initialization value should be looked into, but it doesn't appear that would cause your problem.> I really start thinking it's a flaw in the F88, on the other hand I > can hardly believe that this has to be discovered on my workbench ;)Get real. ;-) Seriously though, something this badly wrong would be documented all over the net.> I'll try a workaround, updating the entire port instead of single > pins.I doctored your code up a bit, see below. You should still add more pseudo-ops for clarification. A proper __CONFIG directive and comments would be nice. ;-) LIST P=16f88 RADIX HEX INCLUDE "p16f88.inc" MOVLW 00 MOVWF PCLATH ; CLRF PCLATH would do the same thing in half the time GOTO 004 NOP CLRF FSR MOVLW 1F ; Select Bank 0 ANDWF STATUS,F BSF STATUS,RP0 ; Select Bank 1 BCF ADCON1,4 ; Set for AVdd and AVss BCF ADCON1,5 MOVF ANSEL,W ; Get ANSEL value ANDLW 80 ; strip all but first bit (unnecessary) IORLW 0F ; make A0 - A3 analog pins, (A4, B6 and B7 as digital) MOVWF ANSEL ; and write it back MOVLW 07 ; ? BCF STATUS,RP0 ; Select Bank 0 MOVWF ADCON0 ; I don't think you want to do this on a 16F88 MOVLW 00 TRIS 5 ; DONT USE THIS INSTRUCTION (deprecated for eons ;-) label: NOP NOP NOP BSF PORTA,2 NOP NOP NOP BCF PORTA,3 NOP NOP NOP BCF PORTA,2 NOP NOP NOP BSF PORTA,3 GOTO label END
Reply by ●December 2, 20042004-12-02
On Thursday, in article
<41af158c$0$566$e4fe514c@news.xs4all.nl>
f.bemelmanx@xs4all.invalid.nl "Frank Bemelman" wrote:
>Strange problem:
>
>Setting an output low on PORTA, causes another output
>on PORTA to go low too.
>
>Below is the entire program. It should generate two signals:
>
>---, ,---, ,---, ,---, ,---
> '---' '---' '---' '---'
>-, ,---, ,---, ,---, ,---
> '- -' '---' '---' '---'
>
>But instead gives this:
>
>-, ,-, ,-, ,-, ,-
> '-----' '-----' '-----' '-----'
>-, ,---, ,---, ,---, ,---
> '- -' '---' '---' '---'
>
>If I generate the second signal on an output of PORTB,
>it all works okay.
......
When something works on one port but not on another for ANY micro
my suggestions are
Check the port has been fully initialised for correct mode
and o/p type.
Check the connections on the pin if necessary open circuit
the pin from the rest of the circuit and test again.
Looks suspiciously like something external to me though.
--
Paul Carpenter | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.gnuh8.org.uk/> GNU H8 & mailing list info
<http://www.badweb.org.uk/> For those web sites you hate
Reply by ●December 2, 20042004-12-02
In message <41af1800$0$48933$e4fe514c@news.xs4all.nl>, Frank Bemelman <f.bemelmanx@xs4all.invalid.nl> writes>"Frank Bemelman" <f.bemelmanx@xs4all.invalid.nl> schreef in bericht >news:41af158c$0$566$e4fe514c@news.xs4all.nl...<Snipped>>> Strange problem: >> >> Setting an output low on PORTA, causes another output >> on PORTA to go low too. > >And also, when I change everything to use outputs >on PORTB, everything also works as expected. Is there >something seriously wrong with PIC16F88 ? >A data point... As it happens, I've been doing something similar today on a '88 using PortA 1..4 to generate four phase overlapping square waves. I've not had any problems. Broken PIC? A short or too much load on one of the port pins? Nice part, though. Cheers -- Keith Wootten
Reply by ●December 2, 20042004-12-02
"Robert Scott" <no-one@dont-mail-me.com> schreef in bericht news:41af3901.9355511@news.provide.net...> On Thu, 2 Dec 2004 15:23:17 +0100, "Frank Bemelman" > <f.bemelmanx@xs4all.invalid.nl> wrote: > > >..Also happens with milisecond delay in > >between. The code I included was just to demonstrate this behaviour.. > > Whenever you use BCF and BSF instructions to set or clear bits on a > port, the entire port is read and then written. If you have enough > loading on the output that it reads back as something other than what > you wrote (i.e. past the half-way point between the voltage supply > rails) then the latch for the port will adopt the forced value. Try > your test with absolutely no loading on the output.Damn, do I feel SILLY. It has happened before, and now it bit me again. I used to have a wrapper for fiddling with single outputs, using intermediate storage, which I didn't use here, and I do have a serious load indeed (some leds on port A etc). Thanks Robert ;) #^*&^!! It won't happen again, I promise. Thanks to all the other respondents too. -- Thanks, Frank. (remove 'x' and 'invalid' when replying by email)
