Is PCM 3.146 or PIC16LF876A broken?

[Pete Smith]

<font face="Courier New" size=-1>Hi all.

As some of you know, I've been trying to get an interrupt driven soft UART working.

Although the code works when connected to a terminal, when I connect it to the final hardware, it just refuses to work full stop. Despite the same data coming in (at a different character rate), it's constantly messed up.

I thought, OK, it's only a prototype, I'll try it on a PIC with a hardware UART.

I didn't have any luck here either.

I've now tried this code. Absolute back to basics stuff, The downside is that it doesn't work, in the slightest!

#include <16F876A.h>
#device PIC16F876A *=16 ADC=10
#fuses nowdt,xt, noprotect, noput, nowrt, nolvp,nobrownout
#use delay (clock=4000000)

#use fast_io(a)
#use fast_io(b)
#use fast_io(c)

#byte port_a=0x05
#byte port_b=0x06
#byte port_c=0x07

#use RS232 (baud=2400, xmit=PIN_C6,rcv=PIN_C7, parity=N, bits=8)

void main(void)
{
set_tris_a(0b00000000);
set_tris_b(0b00000000);
set_tris_c(0b01000000);

while (1==1)
{
printf("S");
}
}

CCS PCM C Compiler, Version 3.146, 14581

Filename: W:\Test\Source\8pinpic\TRMControl\TRM0.5\trm.LST

ROM used: 69 (1\%)
Largest free fragment is 2048
RAM used: 5 (1\%) at main() level
6 (2\%) worst case
Stack: 1 locations

*
0000: MOVLW 00
0001: MOVWF 0A
0002: GOTO 01C
0003: NOP
.................... #include <16F876A.h>
.................... //////// Standard Header file for the PIC16F876A device ////////////////
.................... #device PIC16F876A
.................... #list
....................
.................... #device PIC16F876A *=16 ADC=10
.................... #fuses nowdt,xt, noprotect, noput, nowrt, nolvp,nobrownout
.................... #use delay (clock=4000000)
0004: MOVLW 21
0005: MOVWF 04
0006: BCF 03.7
0007: MOVF 00,W
0008: BTFSC 03.2
0009: GOTO 019
000A: MOVLW 01
000B: MOVWF 78
000C: CLRF 77
000D: DECFSZ 77,F
000E: GOTO 00D
000F: DECFSZ 78,F
0010: GOTO 00C
0011: MOVLW 4A
0012: MOVWF 77
0013: DECFSZ 77,F
0014: GOTO 013
0015: NOP
0016: NOP
0017: DECFSZ 00,F
0018: GOTO 00A
0019: BCF 0A.3
001A: BCF 0A.4
001B: GOTO 043 (RETURN)
....................
.................... #use fast_io(a)
.................... #use fast_io(b)
.................... #use fast_io(c)
....................
.................... #byte port_a=0x05
.................... #byte port_b=0x06
.................... #byte port_c=0x07
....................
.................... #use RS232 (baud=2400, xmit=PIN_C6,rcv=PIN_C7, parity=N, bits=8)
....................
.................... void main(void)
.................... {
001C: CLRF 04
001D: BCF 03.7
001E: MOVLW 1F
001F: ANDWF 03,F
0020: MOVLW 07
0021: BSF 03.5
0022: MOVWF 1F
0023: MOVLW 07
0024: BCF 03.5
0025: MOVWF 1F
0026: MOVLW 07
0027: BSF 03.5
0028: MOVWF 1F
0029: MOVLW 07
002A: BCF 03.5
002B: MOVWF 1F
002C: MOVLW 19
002D: BSF 03.5
002E: MOVWF 19
002F: MOVLW 22
0030: MOVWF 18
0031: MOVLW 90
0032: BCF 03.5
0033: MOVWF 18
.................... set_tris_a(0b00000000);
0034: MOVLW 00
0035: BSF 03.5
0036: MOVWF 05
.................... set_tris_b(0b00000000);
0037: MOVLW 00
0038: MOVWF 06
.................... set_tris_c(0b01000000);
0039: MOVLW 40
003A: MOVWF 07
003B: BCF 03.5
....................
.................... while (1==1)
.................... {
.................... printf("S");
003C: MOVLW 53
003D: BTFSS 0C.4
003E: GOTO 03D
003F: MOVWF 19
.................... delay_ms(10);
0040: MOVLW 0A
0041: MOVWF 21
0042: GOTO 004
.................... }
0043: GOTO 03C
.................... }
....................
0044: SLEEP

Configuration Fuses:
Word 1: 3D39 XT NOWDT NOPUT NOPROTECT NOBROWNOUT NOLVP NOCPD NOWRT


It _should_ print 'S', repeatedly, to the hardware UART. (The 10mS delay is to allow me to sync the incoming to outgoing signals).

It _does_ manage to send "S" to the serial port.

However, despite my having instructed C7 to be an input, C7 is showing the last 6 bits of whatever's being sent to C6.

The PIC has minimal setup. 4MHz resonator to 9,10 and gnd., pin 1 to +3v via a link, 8,19 and 20 to the relevant rails. 8 and 19 to ground and 20 to +3v.

I've even bent Pin C7 away from the board, and isolated it completely, and it's still showing a good strong signal.

The rails are ripple free.

Can anyone stop me going absolutely crackers?

This sort of code has always run before, no problems. It's the sort of code I use to test my boards, to make sure they're OK.

Incrementing port B (another test) works perfectly.

Removing the reference to the receive pin forces the UART to be a software one, and then it does precisely nothing :-(

As it stands, using the hardware UART like this is useless for my code, because as I'm transmitting data, crap is coming back in on the input line, and as I'm displaying the data that should be coming in, the very act of displaying the data causes the incoming data to become corrupted.

Obviously, I've tried different PICs, and they're all the same. I've also tried a known good PIC and hardware platform, which has been fully functional, and using hardware UART, and it does the same thing.

C7 is definitely being switched to an output, because connecting it to ground causes an extra 10mA to be drawn from the supply.

Any advice is appreciated,

Thanks,

Pete.</font>
___________________________
This message was ported from CCS's old forum
Original Post ID: 144516110

[PCM programmer]

:=I've now tried this code. Absolute back to basics stuff, The downside is that it doesn't work, in the slightest!
--------------------------------------------------------

Here is a back to basics program that worked with
PCM vs. 3.146 and a 16F877. (I don't have 16F877A to test).

Try this:
1. Change to +5v supply.
2. Get rid of the resonator and use a crystal.
3. Remove fast i/o and use standard i/o.
4. Make sure MCLR pin goes to solid Vcc (+5v in this case).

#include "c:\Program Files\Picc\Devices\16F877.H"
#fuses HS, NOWDT, NOPROTECT, BROWNOUT, PUT, NOLVP
#use delay(clock = 8000000)
#use rs232(baud = 9600, xmit=PIN_C6, rcv = PIN_C7, ERRORS)

//=========================================================
void main()
{

while(1)
{
putc('S');
}

}

This printed SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS...
on the terminal window.
-----------------------------------------------------
I changed the include file to be 16F877A, and recompiled.
Then I compared the two .LST files. (This is for vs. 3.146).
There is one difference. The 16F877A appears to have a bug
in the initial setup code. It has 2 more lines than the
16F877 code. See below.

<PRE>
0004 0184 00280 CLRF 04
0005 301F 00281 MOVLW 1F
0006 0583 00282 ANDWF 03,F
0007 3007 00283 MOVLW 07
0008 1683 00284 BSF 03.5
0009 009F 00285 MOVWF 1F
000A 3007 00286 MOVLW 07 // This is in 16F877A code
000B 1283 00287 BCF 03.5
000C 009F 00288 MOVWF 1F // So is this line.

Those two lines put 07 into register 1F. That's the ADCON0
register. But setting it to 07, turns on the A/D and sets
the "Go" bit. So it starts an A/D conversion. That probably
isn't going to hurt your test program.

My guess is that they really intended to write to the CMCON
register, and shut off the comparators, but they are writing
to the wrong register address by mistake.

000D 01A0 00289 CLRF 20
000E 300C 00290 MOVLW 0C
000F 1683 00291 BSF 03.5
0010 0099 00292 MOVWF 19
0011 3022 00293 MOVLW 22
0012 0098 00294 MOVWF 18
0013 3090 00295 MOVLW 90
0014 1283 00296 BCF 03.5
0015 0098 00297 MOVWF 18
</PRE>
___________________________
This message was ported from CCS's old forum
Original Post ID: 144516111

[PCM programmer]

:=Configuration Fuses:
:= Word 1: 3D39 XT NOWDT NOPUT NOPROTECT NOBROWNOUT NOLVP NOCPD NOWRT
-------------------------------------------------------------

I also noticed something wrong with the config fuses.

For vs. 3.146, it gives: 3D39

For vs. 3.169, it gives: 3F39

This is with your fuse settings.

The difference is in the WRT1 and WRT0 bits.
They should be set to "11" in binary, which disables
flash program memory write protection. But with vs. 3.146,
they are set to "10", which write-protects 0000 to 00FF.

___________________________
This message was ported from CCS's old forum
Original Post ID: 144516114

[patrickfelstead]

In your statement "set_tris_c(0b01000000);"

It appears to me that you have RC6 (Transmit) and RC7 (Receive) reversed.

You have RC7 (MSB) as an output "0", and RC6 as an input "1". Try swapping them around. Doesn't explain why you were able to trasmit though. I'm a bit puzzled.

Patrick


:=<font face="Courier New" size=-1>Hi all.
:=
:=As some of you know, I've been trying to get an interrupt driven soft UART working.
:=
:=Although the code works when connected to a terminal, when I connect it to the final hardware, it just refuses to work full stop. Despite the same data coming in (at a different character rate), it's constantly messed up.
:=
:=I thought, OK, it's only a prototype, I'll try it on a PIC with a hardware UART.
:=
:=I didn't have any luck here either.
:=
:=I've now tried this code. Absolute back to basics stuff, The downside is that it doesn't work, in the slightest!
:=
:=#include <16F876A.h>
:=#device PIC16F876A *=16 ADC=10
:=#fuses nowdt,xt, noprotect, noput, nowrt, nolvp,nobrownout
:=#use delay (clock=4000000)
:=
:=#use fast_io(a)
:=#use fast_io(b)
:=#use fast_io(c)
:=
:=#byte port_a=0x05
:=#byte port_b=0x06
:=#byte port_c=0x07
:=
:=#use RS232 (baud=2400, xmit=PIN_C6,rcv=PIN_C7, parity=N, bits=8)
:=
:=void main(void)
:={
:= set_tris_a(0b00000000);
:= set_tris_b(0b00000000);
:= set_tris_c(0b01000000);
:=
:= while (1==1)
:= {
:= printf("S");
:= }
:=}
:=
:=CCS PCM C Compiler, Version 3.146, 14581
:=
:= Filename: W:\Test\Source\8pinpic\TRMControl\TRM0.5\trm.LST
:=
:= ROM used: 69 (1\%)
:= Largest free fragment is 2048
:= RAM used: 5 (1\%) at main() level
:= 6 (2\%) worst case
:= Stack: 1 locations
:=
:=*
:=0000: MOVLW 00
:=0001: MOVWF 0A
:=0002: GOTO 01C
:=0003: NOP
:=.................... #include <16F876A.h>
:=.................... //////// Standard Header file for the PIC16F876A device ////////////////
:=.................... #device PIC16F876A
:=.................... #list
:=....................
:=.................... #device PIC16F876A *=16 ADC=10
:=.................... #fuses nowdt,xt, noprotect, noput, nowrt, nolvp,nobrownout
:=.................... #use delay (clock=4000000)
:=0004: MOVLW 21
:=0005: MOVWF 04
:=0006: BCF 03.7
:=0007: MOVF 00,W
:=0008: BTFSC 03.2
:=0009: GOTO 019
:=000A: MOVLW 01
:=000B: MOVWF 78
:=000C: CLRF 77
:=000D: DECFSZ 77,F
:=000E: GOTO 00D
:=000F: DECFSZ 78,F
:=0010: GOTO 00C
:=0011: MOVLW 4A
:=0012: MOVWF 77
:=0013: DECFSZ 77,F
:=0014: GOTO 013
:=0015: NOP
:=0016: NOP
:=0017: DECFSZ 00,F
:=0018: GOTO 00A
:=0019: BCF 0A.3
:=001A: BCF 0A.4
:=001B: GOTO 043 (RETURN)
:=....................
:=.................... #use fast_io(a)
:=.................... #use fast_io(b)
:=.................... #use fast_io(c)
:=....................
:=.................... #byte port_a=0x05
:=.................... #byte port_b=0x06
:=.................... #byte port_c=0x07
:=....................
:=.................... #use RS232 (baud=2400, xmit=PIN_C6,rcv=PIN_C7, parity=N, bits=8)
:=....................
:=.................... void main(void)
:=.................... {
:=001C: CLRF 04
:=001D: BCF 03.7
:=001E: MOVLW 1F
:=001F: ANDWF 03,F
:=0020: MOVLW 07
:=0021: BSF 03.5
:=0022: MOVWF 1F
:=0023: MOVLW 07
:=0024: BCF 03.5
:=0025: MOVWF 1F
:=0026: MOVLW 07
:=0027: BSF 03.5
:=0028: MOVWF 1F
:=0029: MOVLW 07
:=002A: BCF 03.5
:=002B: MOVWF 1F
:=002C: MOVLW 19
:=002D: BSF 03.5
:=002E: MOVWF 19
:=002F: MOVLW 22
:=0030: MOVWF 18
:=0031: MOVLW 90
:=0032: BCF 03.5
:=0033: MOVWF 18
:=.................... set_tris_a(0b00000000);
:=0034: MOVLW 00
:=0035: BSF 03.5
:=0036: MOVWF 05
:=.................... set_tris_b(0b00000000);
:=0037: MOVLW 00
:=0038: MOVWF 06
:=.................... set_tris_c(0b01000000);
:=0039: MOVLW 40
:=003A: MOVWF 07
:=003B: BCF 03.5
:=....................
:=.................... while (1==1)
:=.................... {
:=.................... printf("S");
:=003C: MOVLW 53
:=003D: BTFSS 0C.4
:=003E: GOTO 03D
:=003F: MOVWF 19
:=.................... delay_ms(10);
:=0040: MOVLW 0A
:=0041: MOVWF 21
:=0042: GOTO 004
:=.................... }
:=0043: GOTO 03C
:=.................... }
:=....................
:=0044: SLEEP
:=
:=Configuration Fuses:
:= Word 1: 3D39 XT NOWDT NOPUT NOPROTECT NOBROWNOUT NOLVP NOCPD NOWRT
:=
:=
:=It _should_ print 'S', repeatedly, to the hardware UART. (The 10mS delay is to allow me to sync the incoming to outgoing signals).
:=
:=It _does_ manage to send "S" to the serial port.
:=
:=However, despite my having instructed C7 to be an input, C7 is showing the last 6 bits of whatever's being sent to C6.
:=
:=The PIC has minimal setup. 4MHz resonator to 9,10 and gnd., pin 1 to +3v via a link, 8,19 and 20 to the relevant rails. 8 and 19 to ground and 20 to +3v.
:=
:=I've even bent Pin C7 away from the board, and isolated it completely, and it's still showing a good strong signal.
:=
:=The rails are ripple free.
:=
:=Can anyone stop me going absolutely crackers?
:=
:=This sort of code has always run before, no problems. It's the sort of code I use to test my boards, to make sure they're OK.
:=
:=Incrementing port B (another test) works perfectly.
:=
:=Removing the reference to the receive pin forces the UART to be a software one, and then it does precisely nothing :-(
:=
:=As it stands, using the hardware UART like this is useless for my code, because as I'm transmitting data, crap is coming back in on the input line, and as I'm displaying the data that should be coming in, the very act of displaying the data causes the incoming data to become corrupted.
:=
:=Obviously, I've tried different PICs, and they're all the same. I've also tried a known good PIC and hardware platform, which has been fully functional, and using hardware UART, and it does the same thing.
:=
:=C7 is definitely being switched to an output, because connecting it to ground causes an extra 10mA to be drawn from the supply.
:=
:=Any advice is appreciated,
:=
:=Thanks,
:=
:=Pete.</font>
___________________________
This message was ported from CCS's old forum
Original Post ID: 144516120

[Pete Smith]

:=In your statement "set_tris_c(0b01000000);"
:=
:=It appears to me that you have RC6 (Transmit) and RC7 (Receive) reversed.
:=
:=You have RC7 (MSB) as an output "0", and RC6 as an input "1". Try swapping them around. Doesn't explain why you were able to trasmit though. I'm a bit puzzled.

I realised this at 23:10 last night, when I was in bed, that the assembler was setting trisc to 0x40. But bit 7 was the input, so it should be 0x80.

Unsurprisingly, changing the TRIS to the correct value, and everything works now.

I think that it's a lesson to not program while tired! 12 hours solid work, and I'm not my best any longer :-)

I'm also a little confused as to why it was still able to transmit. Maybe it's one of those hardware UART things.

Thanks,

Pete.
___________________________
This message was ported from CCS's old forum
Original Post ID: 144516127