CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Using 2 UARTS @38400 = PROBLEM, @9600 = OKAY

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
blak3r



Joined: 11 Jan 2004
Posts: 45

View user's profile Send private message Visit poster's website

Using 2 UARTS @38400 = PROBLEM, @9600 = OKAY
PostPosted: Thu May 11, 2006 9:01 am     Reply with quote

Target Details:
18F6527
Clock = 20Mhz Xtal

I am testing my board and i have two serial ports controlled by the pic. To verify they both work i connected them together appropriately. (One is a DTE and one is DCE so i don't need null modem) The UART on PIN G1 & G2 is solid. It always works. But, the one on C6 and C7 isnt.

The code below kept failing - so i hooked up a DLA and found that even though the baud rate was set to 38400 the actual baud rate the uart on c6&c7 was putting out was 10,000bps (period of each bit was 100uS). I then changed the rs232 baud rate to 9600 for both and the code ran successfully.

Any ideas?


Code:
   #use rs232(baud=38400, xmit=PIN_G1, rcv=PIN_G2, ERRORS, STREAM=DB9)
   #use rs232(baud=38400, xmit=PIN_C6, rcv=PIN_C7, ERRORS, STREAM=RJ45)


is how i have them setup.


This is the complete code in my main - variable declarations:



Code:

   lcd_init();
   lcd_putc("Starting loop Tst\r\n");
   
   // CLEARS EACH BUFFER - just in case
   while(kbhit(RJ45) )
      fgetc( RJ45 );
   while(kbhit(DB9 ) )
      fgetc(DB9 );

   // TEST READING CHARS ON - RJ45
   fputc('A', DB9 );
   choice = fgetc( RJ45 );
   
   if( choice == 'A' )
      lcd_putc("SUCCESSFUL READ");
   else {
         lcd_putc("FAILED READ: ");
      lcd_putc( choice );
      printf(lcd_putc, ", 0x%X", choice );
   }
   lcd_putc("\r\n");
   
   // TEST WRITING CHARS ON THE RJ45 Serial Port
   fputc('T', RJ45 );
   choice = fgetc( DB9 );
   
   if( choice == 'T' )
      lcd_putc("SUCCESSFUL WRITE");
   else {
      lcd_putc("FAILED WRIT: ");
      lcd_putc( choice );
      printf(lcd_putc, ", 0x%X", choice );
   }
   lcd_putc("\r\n");

_________________
"Everything should be made as simple as possible, but not one bit simpler" -- Albert Einstein

http://www.blakerobertson.com
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Thu May 11, 2006 9:42 am     Reply with quote

Quote:

Even though the baud rate was set to 38400 the actual baud rate the uart
on c6&c7 was putting out was 10,000bps (period of each bit was 100uS).

Post your compiler version.
blak3r



Joined: 11 Jan 2004
Posts: 45

View user's profile Send private message Visit poster's website

PostPosted: Thu May 11, 2006 10:22 am     Reply with quote

PCM Version 3.184
_________________
"Everything should be made as simple as possible, but not one bit simpler" -- Albert Einstein

http://www.blakerobertson.com
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Thu May 11, 2006 10:56 am     Reply with quote

Quote:
Target Details:
18F6527

PCM Version 3.184

You must mean PCH, because you're using an 18F PIC.

I don't have PCH vs. 3.184. The closest I have is 3.187.
I installed that version and tried to compile a test program for the
18F6527 and I get this error message:
Quote:

Error 24 "C:\PROGRAM FILES\PICC\devices\18F6527.h" Line 2(9,19):
Unknown device type "PIC18F6527"

That version of the compiler doesn't support it. I tried PCH 3.188
and it doesn't support it either.
blak3r



Joined: 11 Jan 2004
Posts: 45

View user's profile Send private message Visit poster's website

PostPosted: Thu May 11, 2006 11:02 am     Reply with quote

You're right,

PCH 3.222

I also have PCM. My mistake.
18F6527 is supported in 3.222
_________________
"Everything should be made as simple as possible, but not one bit simpler" -- Albert Einstein

http://www.blakerobertson.com
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Thu May 11, 2006 12:15 pm     Reply with quote

The closest version I have to yours is PCH vs. 3.231. The .LST file
looks OK for that version. They are setting up both ports to use a
16-bit baud rate generator. The baud rate formula for that mode is:
Code:

   Fosc
-------------   
4 * (n +1)          Note:  n = the 16-bit SPBRG value

which gives:
Code:

20 x 10e6
------------- = 38461.53  baud
4 * (129 +1)

That's very close to the desired value of 38400.

Compile this test program and see if the generated code in the .LST
file matches the .LST file shown below it. Specifically look at the values
that are put into these registers:
BAUDCON1
SPBRG1
SPBRGH1
TXSTA1

Also look at the generated code for fputc(0xAA, RJ45). Make sure
it looks similar to the code shown below. It could be that your version
is creating a software UART instead of using the hardware UART.

Code:

#include <18F6527.h>
#fuses HS, NOWDT, NOPROTECT, NOBROWNOUT, PUT, NOLVP
#use delay(clock=20000000)
#use rs232(baud=38400, xmit=PIN_G1, rcv=PIN_G2, ERRORS, STREAM=DB9)
#use rs232(baud=38400, xmit=PIN_C6, rcv=PIN_C7, ERRORS, STREAM=RJ45)

//==============================
void main()
{
fputc(0x55, DB9);

fputc(0xAA, RJ45);

while(1);
}



Code:
.................... void main() 
.................... { 
0004:  CLRF   FF8
0006:  BCF    FD0.7
0008:  CLRF   FEA
000A:  CLRF   FE9

000C:  BSF    F7C.3  // BAUDCON2  Use 16-bit SPBRG
000E:  MOVLW  81
0010:  MOVWF  F6F    // SPBRG2
0012:  MOVLW  00     
0014:  MOVWF  F7D    // SPBRGH2
0016:  MOVLW  26
0018:  MOVWF  F6C    // TXSTA2
001A:  MOVLW  90
001C:  MOVWF  F6B    // RCSTA2

// Setup register for the UART on pins C6 and C7:
001E:  BSF    F7E.3  // BAUDCON1   Use 16-bit SPBRG
0020:  MOVLW  81
0022:  MOVWF  FAF  // SPBRG1
0024:  MOVLW  00
0026:  MOVWF  F7F  // SPBRGH1
0028:  MOVLW  26
002A:  MOVWF  FAC  // TXSTA1
002C:  MOVLW  90
002E:  MOVWF  FAB  // RCSTA1

0030:  MOVF   FC1,W
0032:  ANDLW  C0
0034:  IORLW  0F
0036:  MOVWF  FC1   // ADCON1
0038:  MOVLW  07
003A:  MOVWF  FB4   // CMCON
003C:  CLRF   05
.................... 
.................... fputc(0x55, DB9);
003E:  MOVLW  55
0040:  BTFSS  FA4.4
0042:  BRA    0040
0044:  MOVWF  F6D
.................... 
.................... fputc(0xAA, RJ45);
0046:  MOVLW  AA
0048:  BTFSS  F9E.4
004A:  BRA    0048
004C:  MOVWF  FAD
blak3r



Joined: 11 Jan 2004
Posts: 45

View user's profile Send private message Visit poster's website

PostPosted: Thu May 11, 2006 2:46 pm     Reply with quote

See lines 0024 and 0036, i believe that's the cause of the bug.

Code:

0004:  CLRF   FF8
0006:  BCF    FD0.7
0008:  CLRF   FEA
000A:  CLRF   FE9

000C:  MOVF   FC1,W
000E:  ANDLW  C0
0010:  IORLW  0F
0012:  MOVWF  FC1
0014:  MOVLW  07
0016:  MOVWF  FB4
0018:  MOVF   FB4,W
001A:  BCF    FA1.6
001C:  BSF    F7C.3
001E:  MOVLW  81
0020:  MOVWF  F6F       // SPBRG2
0022:  MOVLW  00
0024:  MOVWF  F70       // != SPBRGH2 (should be F7D)
0026:  MOVLW  26
0028:  MOVWF  F6C
002A:  MOVLW  90
002C:  MOVWF  F6B
002E:  BSF    F7E.3
0030:  MOVLW  81
0032:  MOVWF  FAF  // SPBRG1
0034:  MOVLW  00
0036:  MOVWF  FB0  // != SPBRGH1  (should be F7F)
0038:  MOVLW  26
003A:  MOVWF  FAC
003C:  MOVLW  90
003E:  MOVWF  FAB
0040:  CLRF   05
.................... fputc(0x55, DB9); 
0042:  MOVLW  55
0044:  BTFSS  FA4.4
0046:  BRA    0044
0048:  MOVWF  F6D
....................   
.................... fputc(0xAA, RJ45); 
004A:  MOVLW  AA
004C:  BTFSS  F9E.4
004E:  BRA    004C
0050:  MOVWF  FAD

_________________
"Everything should be made as simple as possible, but not one bit simpler" -- Albert Einstein

http://www.blakerobertson.com
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Thu May 11, 2006 3:50 pm     Reply with quote

According to the data sheet, the SPBRGH1 and SPBRGH2 registers are
set to 0x00 upon power-on reset. So that bug probably isn't a problem.
It's writing 0x00 to the CCP5CON and PSPCON registers by mistake,
but those registers are also set to 0x00 upon power-on reset.

Just to be sure, you could add the following code to your program
to test it.
Code:
#byte SPBRGH1 = 0xF7F
#byte SPBRGH2 = 0xF7D

void main()
{

SPBRGH1 = 0;
SPBRGH2 = 0;


Also, can you try the small program that I posted ? Does it also
cause the problem with the incorrect baud rate on Pin C6 ?
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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