topic Re: mpc8360 UCC7 UART issue: BRGC sometimes locked incorrect baud rates for autobaud, any solution? in Other NXP Products

mpc8360 UCC7 UART issue: BRGC sometimes locked incorrect baud rates for autobaud, any solution?

gluo — Thu, 04 May 2017 14:54:28 GMT

I am working on a project which is using mpc8360 UCC7 UART auto baud feature.
mpc8360 ERRATA indicated that mpc8360 UCC7 UART autbobaud has a hardware bug of missing autbobaud rate locking interrupt event . The ERRATA also proposed a work-around.

However, even when using this work-around, it looks that mpc8360 UCC7 UART auto baud has the following issue, seen from our testing:

BRGC6 (for UCC7) sometimes locked incorrect baud rates for autobaud.

Our connection configuration is as below:

[ MCP8360 UCC7 DTE (autobaud) ] <-------------> [XyplexTerminalSeverDCE (fixed baud rate 19200)]

Our testing results are as below:
When manually using mpc8360 UCC7 UART auto baud feature,

Expected Results (good cases): mpc8360 BRGC6 sometime could lock the correct baud rates as below:

----------- UCC7 Stats (BRGC:0x1250a [RST:0,EN:1,ATB:1, Operation Baud Rate:19349]) ------------

Incorrect Results (bad cases): However, mpc8360 BRGC6 frequently locked the incorrect baud rates as below:

----------- UCC7 Stats (BRGC:0x127c8 [RST:0,EN:1,ATB:1, Operation Baud Rate:12537]) ------------
----------- UCC7 Stats (BRGC:0x12772 [RST:0,EN:1,ATB:1, Operation Baud Rate:13102]) ------------
----------- UCC7 Stats (BRGC:0x1279a [RST:0,EN:1,ATB:1, Operation Baud Rate:12833]) ------------

May you help us to figure out the possible issues of incorrect locked baud rate?

Furthermore, in section 21.8.1 Autobaud Limitations of MPC8360ERM_Rev2.pdf, it said "When using the Autobaud mode, the clock source used by the BRG (internal or external), must be at least 128-times faster than the target divided clock."

Is "the clock source used by the BRG" brgclk mentioned in 21.9? (our brgClk = 200000001)
What is "the target divided clock"? For example, if the DCE has the fixed rate of 19200, what is the corresponding "the target divided clock"?

PS: further information:

========= procedure of manually Trigger MPC8360 UCC7 UART autobaud =======
1. BRGC programing: Unset EN, set RST and program the new value (e.g. 38400) according to section 21.7.1 of MPC8360ERM_Rev2.pdf

Result: BRGC6=0x1028a [RST:0,EN:1,ATB:0, Operation Baud Rate:38343]
2. Set UCCM[Rx] and UCCM[AB].

    Set MRBLR to 1 (BD contains 1 char) on system initialization.
3. Waiting for Rx Receive data (i.e. waiting for UCCE[Rx] set) for setting ATB bit at BRGC register.
4. Set EN & ATB bits at BRGC register for triggering MPC8360 BRGC autobaud
     mechanism that sets BRGCx[CD] and BRGCx[DIV16]
5. Waiting for Rx Receive data by checking whether UCCE[Rx] is set.
    note: This UCCE[Rx] bit is used instead of the UCCE[AB] bit since it does not work due to this erratum: MPC8360ECE_errata.pdf
6. Received the first (Rx) after setting EN & ATB bits at BRGC.
    At this point, BRGC is expected to lock up the incoming baud rate by setting BRGCx[CD] and BRGCx[DIV16].

software will read BRGCx[CD] and BRGCx[DIV16], and re-setting them to one of closest standards baud rates (i.e, 9600, 19200, ..., 115200)

Re: mpc8360 UCC7 UART issue: BRGC sometimes locked incorrect baud rates for autobaud, any solution?

Pavel — Wed, 10 May 2017 01:36:00 GMT

The Section 21.8.1 means that BRG divider should be more than 128. For your setting this divider is 651. Your setting is correct for autobaud.

Are there mistakes or errors if correct baud rate is set and data are received/transmitted by UCC UART?

Have a great day,
Pavel Chubakov

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

Re: mpc8360 UCC7 UART issue: BRGC sometimes locked incorrect baud rates for autobaud, any solution?

gluo — Thu, 18 May 2017 18:15:39 GMT

There was no any errors after the correct baud rate was set.

We have repeated the testing. It looks that you are correct on the possible impact of BRK on autobaud.

We monitored the input signals with a scope.

It looks that UCC7 did declare the reception of bytes and BRKs that were not sent by DCE at all (confirmed with scope), although we did not see any un-expected BRK or un-expected characters to UCC7 Rx through the scope.

For example,

one byte (0x35, for ‘5’ ) from DCE was declared at UCC7 as three Rx events with bytes 0x1c 0xfc 0xfc. (see Test Case Group 1)
one byte (0x41, for ‘A’) from DCE was declared at UCC7 as one Rx event with byte 0x1c and a BRK event (see Test Case Group 2)

It was found in the following two group of test cases that

a specific set of characters seems to always trigger correct BRGC baud rate locking (Test Case Group 1), and
an another specific set of characters (Test Case Group 2) always trigger incorrect BRGC baud rate locking. In these cases, the un-existing BRKs from DCE were always reported by UCC7 UCCE register.

-------Test Case Group 1: (correct baud locking cases, no BRKs)

DCE(19200) send Rx single "5" (Screenshot_2017-05-10_05_105717.png)

UCC7 saw 3 Rx: 0x1c 0xfc 0xfc locked_brgc=0x1268a (locked_baud:14916) locked baud close to 19200/ok_translate!

rxbd Stat Len DataPtr Data

0x26278040 0x1800 0x0001 0x2627b000 0x1c E:0 W:0 I:1 C:1 A:0 CM:0 ID:0 AM:0 BR:0 FR:0 PR:0 OV:0 CD:0

0x26278048 0x1010 0x0001 0x2627b001 0xfc E:0 W:0 I:1 C:0 A:0 CM:0 ID:0 AM:0 BR:0 FR:1 PR:0 OV:0 CD:0 ERROR

0x26278050 0x1800 0x0001 0x2627b002 0xfc E:0 W:0 I:1 C:1 A:0 CM:0 ID:0 AM:0 BR:0 FR:0 PR:0 OV:0 CD:0

three RX events received, no brk.

7: ucce=0x1[AB:0,IDL:0,GRA:0,BRKE:0,BRKS:0,CCR:0,BSY:0,TX:0,RX:1]

8: ucce=0x1[AB:0,IDL:0,GRA:0,BRKE:0,BRKS:0,CCR:0,BSY:0,TX:0,RX:1]

9: ucce=0x1[AB:0,IDL:0,GRA:0,BRKE:0,BRKS:0,CCR:0,BSY:0,TX:0,RX:1]

note from testing:

characters (4 5, 6, 7, 9, D to I, Q, T to Y, a to o, s to z) triggered corrected BRGC locked baud mostly.

-------Test Case Group 2: (incorrect baud locking cases), with BRKs

Step1: DCE(19200) send Rx single "A" (Screenshot_2017-05-10_06_110124.png)

Step2: UCC7 saw 1 Rx: 0x1c

rxbd Stat Len DataPtr Data

0x26278040 0x1810 0x0001 0x2627b000 0x1c E:0 W:0 I:1 C:1 A:0 CM:0 ID:0 AM:0 BR:0 FR:1 PR:0 OV:0 CD:0 ERROR

ucce=0x1[AB:0,IDL:0,GRA:0,BRKE:0,BRKS:0,CCR:0,BSY:0,TX:0,RX:1]

UCC7 also saw an unexpected BRKS event which does not exist according to the scope

ucce=0x60[AB:0,IDL:0,GRA:0,BRKE:1,BRKS:1,CCR:0,BSY:0,TX:0,RX:0]

Step 3: DCE(19200) send Rx single "A" again (Screenshot_2017-05-10_07_110302.png)

Step 4: UCC7 saw 2 Rx: 0x1c 0xF8 locked_brgc=0x1203e (locked_baud:390625) locked baud far away from 19200!

rxbd Stat Len DataPtr Data

0x26278040 0x1810 0x0001 0x2627b000 0x1c E:0 W:0 I:1 C:1 A:0 CM:0 ID:0 AM:0 BR:0 FR:1 PR:0 OV:0 CD:0 ERROR

0x26278048 0x1800 0x0001 0x2627b001 0xf8 E:0 W:0 I:1 C:1 A:0 CM:0 ID:0 AM:0 BR:0 FR:0 PR:0 OV:0 CD:0

there is no brks:

ucce=0x1[AB:0,IDL:0,GRA:0,BRKE:0,BRKS:0,CCR:0,BSY:0,TX:0,RX:1]

Step 5: DCE(19200) send Rx "AAAAAAAAAA"

Step 6: UCC7 saw fc f0 f0 f0 fe f0 f0 f0 f0 f0 note: there was no errors reported by BD status for receiving "AAAAAAAAAA"

note from testing:

characters ( 0,12,3,8, and all letters except for "D to I, Q, T to Y, a to o, s to z") triggered uncorrected BRGC locked baud.