|
|
View previous topic :: View next topic |
Author |
Message |
bkamen
Joined: 07 Jan 2004 Posts: 1615 Location: Central Illinois, USA
|
[SOLVED] PIC24FJ128GA010 UART2 bit errors |
Posted: Sun Jan 24, 2010 2:41 am |
|
|
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
|
|
Posted: Sun Jan 24, 2010 3:20 am |
|
|
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
|
|
Posted: Sun Jan 24, 2010 3:29 am |
|
|
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
|
|
Posted: Sun Jan 24, 2010 2:09 pm |
|
|
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
|
|
Posted: Sun Jan 24, 2010 2:53 pm |
|
|
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
|
|
Posted: Sun Jan 24, 2010 3:20 pm |
|
|
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
|
|
Posted: Sun Jan 24, 2010 3:28 pm |
|
|
(nod)
-Ben _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
|
|
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
|