PIC16F88, PORTA strange behaviour

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)
Reply to
Frank Bemelman
Loading thread data ...

"Frank Bemelman" schreef in bericht news:41af158c$0$566$ snipped-for-privacy@news.xsall.nl...

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 to
Frank Bemelman

"Frank Bemelman" wrote in news:41af158c$0$566$ snipped-for-privacy@news.xsall.nl:

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 to
Mark A. Odell

"Mark A. Odell" schreef in bericht news:Xns95B35A85127CFCopyrightMarkOdell@130.133.1.4...

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 to
Frank Bemelman

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 to
Robert Scott

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 to
CBarn24050

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.

Get real. ;-) Seriously though, something this badly wrong would be documented all over the net.

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 to
Anthony Fremont

......

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
    PC Services
 Click to see the full signature
Reply to
Paul Carpenter

In message , Frank Bemelman writes

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 to
Keith Wootten

"Robert Scott" schreef in bericht news: snipped-for-privacy@news.provide.net...

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)
Reply to
Frank Bemelman

"Frank Bemelman" wrote in news:41af250b$0$559$ snipped-for-privacy@news.xsall.nl:

As Robert Scott pointed out, a different load on the pins can make one port appear to work and another not. I hit this problem when trying to toggle two different bits on the same port at the CPUs instruction rate (10MHz on a PIC18F242), even with a very light load (scope probes only) on the pins I experienced your problem. This high-speed problem is noted by Microchip as problem to be worked around and as you've found, it can be a problem at lower update rates depending upon loading.

Glad you have a solution.

--
- Mark ->
--
Reply to
Mark A. Odell

"Mark A. Odell" schreef in bericht news:Xns95B399C5B15CDCopyrightMarkOdell@130.133.1.4...

Yes, me too. I feel a bit silly, me saying 'No, it's not that', because this problem has happened to me before. But all is well that ends well ;)

--
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)
Reply to
Frank Bemelman

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.