|
|
View previous topic :: View next topic |
Author |
Message |
tamagee
Joined: 02 Sep 2009 Posts: 6
|
rs232 putc freeze |
Posted: Fri Sep 04, 2009 6:04 pm |
|
|
Problem with rs232 output on 18F26J50. Code freezes at putc command. Same with printf. With serial calls commented out, program runs fine.
Code: |
#include <18f26j50.h>
//#device icd=true
#fuses INTRC_IO,NOWDT,NOPROTECT,
#use delay(clock=8M,internal)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7,stream=COM_A, ERRORS,BRGH1OK)
#include <input.c>
#include <stdlib.h>
#include <stdio.h>
#INT_RDA
void serial_isr()
{
}
#int_default
default_isr() {
}
void main (void)
{
disable_interrupts(GLOBAL);
// configure USART
set_tris_c(10000000);
while(1) {
delay_ms(100);
putc('U');
//printf("U");
output_high(PIN_A1);
delay_ms(100);
output_low(PIN_A1);
delay_ms(100);
}
} |
|
|
|
tamagee
Joined: 02 Sep 2009 Posts: 6
|
|
Posted: Fri Sep 04, 2009 9:26 pm |
|
|
From the asm listing, Getting an infinite loop at lines 154/156
4: #use rs232(BAUD=19200, parity=N, bits=8,uart1, ERRORS,BRGH1OK)
00A2 AA9E BTFSS 0xf9e, 0x5, ACCESS
00A4 D7FE BRA 0xa2
00A6 CFAB MOVFF 0xfab, 0x18
00AA CFAE MOVFF 0xfae, 0x1
00AE A218 BTFSS 0x18, 0x1, ACCESS
00B0 D002 BRA 0xb6
00B2 98AB BCF 0xfab, 0x4, ACCESS
00B4 88AB BSF 0xfab, 0x4, ACCESS
00B6 EF7E GOTO 0xfc
0154 A89E BTFSS 0xf9e, 0x4, ACCESS
0156 D7FE BRA 0x154
0158 6EAD MOVWF 0xfad, ACCESS
015A EFD5 GOTO 0x1aa |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Sat Sep 05, 2009 1:08 am |
|
|
Quote: | set_tris_c(10000000); |
You're setting the TRIS to 10 million. You don't actually need to set TRIS.
But if you do, and you if use a binary number, you need to prefix it with
"0b".
But to test your problem, I made a little test program:
Code: | #include <18F26J50.h>
#fuses INTRC_IO, NOWDT
#use delay(clock=8M,internal)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7, ERRORS)
//=====================================
void main()
{
int8 c;
while(1)
{
c = getc();
putc(c);
}
} |
I compiled it with vs. 4.098 and found a large number of problems
with the UART1 code, as shown below. I don't have vs. 4.099 to test
at the moment. I can test it on Sunday, maybe. But if you have 4.098,
your serial code just won't work. The generated ASM code is too buggy.
The basic problem is that CCS is using a register map that is suitable
for the 18F452, etc., nut these "J-series" PICs have a different register
map. Maybe they fixed it in 4.099. I'll check it later in the weekend.
Code: |
.... #use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7, ERRORS)
// getc():
0004: BTFSS F9E.5 // PIR1.RC1IF
0006: BRA 0004
0008: MOVFF FAB,05 // SPBRG2 *** BUG: Wrong register
000C: MOVFF FAE,01 // TXREG1 *** BUG: Wrong register
0010: BTFSS 05.1
0012: BRA 0018
0014: BCF FAB.4 // SPBRG2 *** BUG: Wrong register
0016: BSF FAB.4 // SPBRG2 *** BUG: Wrong register
0018: GOTO 0054 (RETURN)
// putc():
001C: BTFSS F9E.4 // PIR1.TX1IF
001E: BRA 001C
0020: MOVWF FAD // TXSTA1
0022: GOTO 005C (RETURN)
...
... //=========================================
... void main()
... {
0026: CLRF FF8
0028: BCF FD0.7
002A: CLRF FEA
002C: CLRF FE9
002E: CLRF F9B // OSCTUNE
0030: MOVLW 70
0032: MOVWF FD3 // OSCCON
0034: MOVF FD3,W
0036: BCF FB8.3 // ECC2PAS *** Bug: Not needed
0038: MOVLW 0C
003A: MOVWF FAF // RCREG1 *** Bug: Not needed
003C: MOVLW A2
003E: MOVWF FAC // RCSTA1
0040: MOVLW 90
0042: MOVWF FAB // SPBRG2 *** Bug: Wrong register
0044: MOVF FC1,W // ADCON1
0046: ANDLW C0
0048: IORLW 0F
004A: MOVWF FC1
004C: MOVLW 07
004E: MOVWF FB4 // CCP2CON *** Bug: Wrong register
0050: CLRF 05
.................... int8 c;
....................
.................... while(1)
.................... {
.................... c = getc();
0052: BRA 0004
0054: MOVFF 01,06
.................... putc(c);
0058: MOVF 06,W
005A: BRA 001C
.................... }
005C: BRA 0052
....................
.................... }
|
|
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Sun Sep 06, 2009 3:12 pm |
|
|
Vs. 4.099 has the same bugs for the 18F26J50 and 18F46J50.
I just sent CCS a detailed email on it. Here's part of it:
Quote: |
Here is the annotated .LST file, showing all the bugs in the register addresses.
.... #use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7, ERRORS)
// getc():
0004: BTFSS F9E.5 // PIR1.RC1IF
0006: BRA 0004
0008: MOVFF FAB,05 // SPBRG2 *** Bug: Should be RCSTA1 at register address 0xFAC
000C: MOVFF FAE,01 // TXREG1 *** Bug: Should be RCREG1 at register address 0xFAF
0010: BTFSS 05.1
0012: BRA 0018
0014: BCF FAB.4 // SPBRG2 *** Bug: Should be RCSTA1 at register address 0xFAC
0016: BSF FAB.4 // SPBRG2 *** Bug: Should be RCSTA1 at register address 0xFAC
0018: GOTO 0054 (RETURN)
// putc():
001C: BTFSS F9E.4 // PIR1.TX1IF
001E: BRA 001C
0020: MOVWF FAD // TXSTA1 *** Bug: Should be TXREG1 at register address 0xFAE
0022: GOTO 005C (RETURN)
...
... //=========================================
... void main()
... {
0026: CLRF FF8
0028: BCF FD0.7
002A: CLRF FEA
002C: CLRF FE9
002E: CLRF F9B // OSCTUNE
0030: MOVLW 70
0032: MOVWF FD3 // OSCCON
0034: MOVF FD3,W
0036: BCF FB8.3 // ECC2PAS *** Bug: Should be BAUDCON1 register address at 0xF7E
0038: MOVLW 0C
003A: MOVWF FAF // RCREG1 *** Bug: Should be SPBRG1 register address at 0xFB0
003C: MOVLW A2
003E: MOVWF FAC // RCSTA1 *** Bug: Should be TXSTA1 register address at 0xFAD
0040: MOVLW 90
0042: MOVWF FAB // SPBRG2 *** Bug: Should be RCSTA1 register address at 0xFAC
0044: MOVF FC1,W // ADCON1
0046: ANDLW C0
0048: IORLW 0F
004A: MOVWF FC1
004C: MOVLW 07
004E: MOVWF FB4 // CCP2CON *** Bug: Should be CMCON register address at 0xFD2
// But, additional bug: The comparator registers in the 18F46J50-series
// don't have the same bit assignments as in the 18F4520. So it's not
// valid to write 0x07 to it. This all has to be cleaned up.
0050: CLRF 05
.................... int8 c;
....................
.................... while(1)
.................... {
.................... c = getc();
0052: BRA 0004
0054: MOVFF 01,06
.................... putc(c);
0058: MOVF 06,W
005A: BRA 001C
.................... }
005C: BRA 0052
....................
.................... }
// This test program is just concerning the UART registers. It's possible
// that all the rest of the registers are screwed up as well.
|
|
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Wed Jan 13, 2010 2:07 pm |
|
|
Here is the generated code for vs. 4.104. They fixed almost all of it. I've
added comments to lines that were previously buggy, but are now fixed.
Code: |
0004: BTFSS F9E.5
0006: BRA 0004
0008: MOVFF FAC,04 // RXSTA1 *** Fixed
000C: MOVFF FAF,01 // RCREG1 *** Fixed
0010: BTFSS 04.1
0012: BRA 0018
0014: BCF FAC.4 // RCSTA1.CREN *** Fixed
0016: BSF FAC.4 // RCSTA1.CREN *** Fixed
0018: GOTO 005C (RETURN)
001C: BTFSS F9E.4
001E: BRA 001C
0020: MOVWF FAE
0022: GOTO 0064 (RETURN)
....................
.................... //=====================================
.................... void main()
.................... {
0026: CLRF FF8
0028: BCF FD0.7
002A: CLRF FEA
002C: CLRF FE9
002E: CLRF F9B
0030: MOVLW 70
0032: MOVWF FD3
0034: MOVF FD3,W
0036: BCF F7E.3 // BAUDCON.BRG16 *** Fixed
0038: MOVLW 0C
003A: MOVWF FB0 // SPBRG1 *** Fixed
003C: MOVLW A2
003E: MOVWF FAD // TXSTA1 *** Fixed
0040: MOVLW 90
0042: MOVWF FAC // RXSTA1 *** Fixed
0044: MOVLW FF
0046: MOVLB F
0048: MOVWF x48 // ANCON0 = all digital *** Fixed
004A: BCF FC2.6 // ADCON0.VCFG0 *** Fixed
004C: BCF FC2.7 // ADCON0.VCFG1 *** Fixed
004E: MOVLW FF
0050: MOVWF x49 // ANCON1 = all digital *** Mostly Fixed
// There is a slight bug in the section above. It turns on the
// Band Gap voltage generator when it's not needed. They
// really should have moved 0x1F into ANCON1. But it's not
// that important. If you want to turn it off, then use a #bit
// statement to define the address of the bit, above main():
// #bit VBGEN = 0xF49.7
// Then write a 0 to that bit in main():
// VBGEN = 0;
0052: MOVLW 07
0054: MOVWF FB4 // CCP2CON *** Still a Bug
// I believe their goal was to turn off the two comparators, but
// the CM1CON and CM2CON registers are at 0xFD2 and 0xFD1.
// However, the comparators are turned off by default upon
// power-on reset of the PIC anyway.
// Writing 0x07 to CCP2CON puts the CCP2 module in this mode:
// "Capture mode, every 16th rising edge". To turn it off, just add
// this line to the start of main(): setup_ccp2(CCP_OFF);
0056: CLRF 04
|
Just now, I emailed CCS support about the items listed above. |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|