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 CCS Technical Support

[SOLVED] PIC24FJ128GA010 UART2 bit errors

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



Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA

View user's profile Send private message

[SOLVED] PIC24FJ128GA010 UART2 bit errors
PostPosted: Sun Jan 24, 2010 2:41 am     Reply with quote

I'm using PCD 4.104 w/Explorer16 and working up a prototype for something that uses UART2.

I'm wrote a loopback test and am finding even though my scope says everything is correct down to CCS's calc for U1BRG, the received chars in U1RXREG are slightly mangled about 25-50% of the time. (I put my scope right on U1RX and monitored and incoming timing is .01uS of microchip estimated bit-times at Tcy=16MHz w/BRGH = 1 and U1BRG = 34)

I don't think CCS code is the problem as I even replaced some of the getc routines with my own code.

Has anyone else seen problems like this?
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D


Last edited by bkamen on Sun Jan 24, 2010 2:53 pm; edited 1 time in total
FvM



Joined: 27 Aug 2008
Posts: 2337
Location: Germany

View user's profile Send private message

PostPosted: Sun Jan 24, 2010 3:20 am     Reply with quote

Quote:
the received chars in U1RXREG are slightly mangled about 25-50% of the time
What do you exactly observe?

Quote:
incoming timing is .01uS of microchip estimated bit-times

UART timing can't be but in integer multiples of tcy. The only possible cause for a timing deviation in this
order of magnitude is an oscillator frequency error.

Anyway, in loopback, Rx and Tx are using the same timebase.

P.S.: There are several silicon errata listed for revision A chips, below a somewhat cryptic description of an issue,
that may be related to your problems. It's particularly unclear to me, what "some optimal UxBRG values" means.

Quote:
When the UART is in High-Speed mode, BRGH (UxMODE<3>) is set, some optimal UxBRG values can cause reception to fail.

Work around
Test UxBRG values in the application to find a UxBRG value that works consistently for more high-speed applications. User should verify that
the UxBRG baud rate error does not exceed the application limits.


Last edited by FvM on Sun Jan 24, 2010 3:30 am; edited 1 time in total
bkamen



Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA

View user's profile Send private message

PostPosted: Sun Jan 24, 2010 3:29 am     Reply with quote

Yep. I know...

and I thought of the main xtal being off... I checked it with the counter on my scope (Agilent MSO6054a) and it's 8.000MHz.

And, the bit times of the output match up exactly with the listed timing specs in the datasheet.

It's really weird.

I'll get some more detail on the garbage bytes after I get some sleep.

-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D
bkamen



Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA

View user's profile Send private message

PostPosted: Sun Jan 24, 2010 2:09 pm     Reply with quote

Check it out:



the scope (when I zoom in) says the pulse is 8.76uS.

This corresponds within .01uS to the datasheet that says with a 16MHz Tcy, BRGH = 0 and BRG = 34 should equal.

So that says my crystal on the Explorer16 of 8MHz going through the 4xPLL then /2 = 16MHz is pretty spot on.

Also, using the store-mode of the scope and just holding the M key, I see nothing but the expected 'm' char on U2RX all the time.

My code looks like:

Code:
if ( kbhit(COMM) ) {
   c = U1RXREG;
// U2TXREG = c;  // this is commented out as a test
  if ( c != 'm' ) {
      fprintf(DEBUG, "%02X != %02X\r\n", 'm', c);
   }
}


which results in this asm:

Code:
150:                     if ( kbhit(COMM) ) {
 00B2A  AE0222     btss.b 0x0222,#0
 00B2C  370023     bra 0x000b74
151:                        c = U1RXREG;
 00B2E  BFC226     mov.b 0x0226,0x0000
 00B30  B7E860     mov.b 0x0000,0x0860
152:               //         U2TXREG = c;
153:                        if ( c != 'm' ) {
 00B32  804304     mov.w 0x0860,0x0008
 00B34  B2C6D4     xor.b #0x6d,0x0008
 00B36  32001E     bra z, 0x000b74
154:                           fprintf(DEBUG, "%02X != %02X\r\n", 'm', c);
 00B38  2006D0     mov.w #0x6d,0x0000
 00B3A  207021     mov.w #0x702,0x0002
 00B3C  02071E     call 0x00071e
 00B40  200041     mov.w #0x4,0x0002
 00B42  780001     mov.w 0x0002,0x0000
 00B44  020302     call 0x000302
 00B48  E80081     inc.w 0x0002,0x0002
 00B4A  781F81     mov.w 0x0002,[0x001e++]
 00B4C  AF2233     btsc.b 0x0233,#1
 00B4E  37FFFE     bra 0x000b4c
 00B50  8811A0     mov.w 0x0000,0x0234
 00B52  7800CF     mov.w [--0x001e],0x0002
 00B54  200070     mov.w #0x7,0x0000
 00B56  E60800     cpsgt.w 0x0002,0x0000
 00B58  37FFF4     bra 0x000b42
 00B5A  BFC860     mov.b 0x0860,0x0000
 00B5C  EF6001     clr.b 0x0001
 00B5E  207021     mov.w #0x702,0x0002
 00B60  02071E     call 0x00071e
 00B64  AF2233     btsc.b 0x0233,#1
 00B66  37FFFE     bra 0x000b64
 00B68  2000D4     mov.w #0xd,0x0008
 00B6A  8811A4     mov.w 0x0008,0x0234
 00B6C  AF2233     btsc.b 0x0233,#1
 00B6E  37FFFE     bra 0x000b6c
 00B70  2000A4     mov.w #0xa,0x0008
 00B72  8811A4     mov.w 0x0008,0x0234
155:                        }
156:                     }



what I see is typically:

0x6F (0b0110:1111)
0xEF (0b1110:1111)
0xFF (0b1111:1111)

when it should be 0x6D (0x0110:1101)

HOw funky is this?

-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D
bkamen



Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA

View user's profile Send private message

PostPosted: Sun Jan 24, 2010 2:53 pm     Reply with quote

ok...

So as I sat here playing with this NOW, I see the pulse time has changed from 8.76uS to 8.4 to 8.6uS and that seems to crop a lot of bit errors.

So I forced BRGH = 0 and BRG = 8 and life is good.

Wow that bugs me that the BRGH=1 is closer to 115.2 (114.285) than BRGH=0 (115.2 is more like 111.111 at 3.38% off) and it works like crap.

I'd have to do the math to figure out the tolerance of the BRGH's /4 vs /16 timers.. BUT anyway...

-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D
FvM



Joined: 27 Aug 2008
Posts: 2337
Location: Germany

View user's profile Send private message

PostPosted: Sun Jan 24, 2010 3:20 pm     Reply with quote

Your observation seems to confirm the Microchip PIC24FJ128GA010 Rev. A silicon errata sheets.
In my own words, they say, that some BGRH=1 baud rates are not correct.
bkamen



Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA

View user's profile Send private message

PostPosted: Sun Jan 24, 2010 3:28 pm     Reply with quote

(nod)

-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D
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