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:
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]) ------------
----------- 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]) ------------
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."
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)
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!
-----------------------------------------------------------------------------------------------------------------------
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,
It was found in the following two group of test cases that
-------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]
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.