16F88 Port A Problems

[STEELWATER]

16F88 processor and 3.241 compiler

In the following code, setting pin A1 low also causes pin A6 to go low. Also did the same thing when LEDA was configured on pin A4.

If I assert A1 high, it does not cause A6 to go high, and it has been verified that there is not a trace short between A1 and A6.

Any ideas why setting A1 low would cause A6 to also go low?

//C CODE
output_high(LEDA); //pin A6
delay_ms(1000);
output_low(MEM_CS); //pin A1
while(1);

//FROM LST FILE
.................... output_high(LEDA);
0C49: BCF 05.6
0C4A: BCF 03.5
0C4B: BSF 05.6
.................... delay_ms(1000);
0C4C: MOVLW 04
0C4D: MOVWF 72
0C4E: MOVLW FA
0C4F: MOVWF 7C
0C50: BCF 0A.3
0C51: CALL 065
0C52: BSF 0A.3
0C53: DECFSZ 72,F
0C54: GOTO 44E
.................... output_low(MEM_CS);
0C55: BSF 03.5
0C56: BCF 05.1
0C57: BCF 03.5
0C58: BCF 05.1
.................... while(1);
0C59: GOTO 459

Robert Carter
rcarter@steelwater.com
www.steelwater.com

[STEELWATER]

I have simplified the C code down to its roots, and problem still remains. Taking pin A1 low causes A6 to also go low (or float?). If I REM out the output_low(PIN_A6) line, A6 will remain high, as intended.

Below is full C code and LST
------------------------------------
//C CODE
#include <16F88.h>

#fuses intrc_io,nowdt,put,nomclr,nobrownout,nolvp,nocpd,nowrt,nodebug,ccpb0,noprotect,nofcmen,noieso
#use delay(clock=8000000)

void main()
{
output_high(PIN_A6);
output_low(PIN_A1);
}

//LST
CCS PCM C Compiler, Version 3.241, 14-Dec-05 10:54

Filename: 460102XX.lst

ROM used: 26 words (1%)
Largest free fragment is 2048
RAM used: 5 (3%) at main() level
5 (3%) worst case
Stack: 0 locations

*
0000: MOVLW 00
0001: MOVWF 0A
0002: GOTO 004
0003: NOP
.................... #include <16F88.h>
.................... //////// Standard Header file for the PIC16F88 device ////////////////
.................... #device PIC16F88
.................... #list
....................
....................
.................... #fuses intrc_io,nowdt,put,nomclr,nobrownout,nolvp,nocpd,nowrt,nodebug,ccpb0,noprotect,nofcmen,noieso
.................... #use delay(clock=8000000)
....................
.................... void main()
0004: CLRF 04
0005: MOVLW 1F
0006: ANDWF 03,F
0007: MOVLW 70
0008: BSF 03.5
0009: MOVWF 0F
000A: MOVF 0F,W
000B: BCF 1F.4
000C: BCF 1F.5
000D: MOVF 1B,W
000E: ANDLW 80
000F: MOVWF 1B
0010: MOVLW 07
0011: MOVWF 1C
.................... {
.................... output_high(PIN_A6);
0012: BCF 05.6
0013: BCF 03.5
0014: BSF 05.6
.................... output_low(PIN_A1);
0015: BSF 03.5
0016: BCF 05.1
0017: BCF 03.5
0018: BCF 05.1
.................... }
0019: SLEEP

Configuration Fuses:
Word 1: 3F10 NOWDT PUT NOMCLR NOBROWNOUT NOLVP NOCPD NOWRT NODEBUG CCPB0 NOPROTECT INTRC_IO
Word 2: 3FFC NOFCMEN NOIESO

[PCM programmer]

This sounds like a Read-Modify-Write problem. Describe your LED
circuit. Do you have a series resistor between pin A6 and the LED ?
If so, what is the value of the resistor ?

[STEELWATER]

Turns out that was the problem. Using a Hewlett Packard HLMP-4000 LED in a circuit that was designed for 3.0V and with the LED operating around 25mA (even up to 30mA, but we won't tell anybody). Circuit works good at 3.0V.

Well stupid me has been feeding the circuit 5.0V, during development, to satisfy the ICD programming requirements. This, of course, increases the load to the point that the read-modify-write issue comes into play. Even with a 5 second delay, the read-modify-write fails.

Scaling back the load within spec for all operating conditions takes care of the problem.

Thank you for the feedback PCM Programmer. I'm always curious as to the motivation. Your responses on the CCS Forum are timely, informative, and a great asset to the forum as a whole.

Bob Carter