MPC8323 problem to send byte on UCC device with low baud rate

[mathieuguithon]

Hello,

I am using the UCCs device of an MPC8323 controller but I have some problem when I use low baud rate value.

 Context:

 My society created a specific board with a MPC8323 controller for railways industrials application.

 To validate the UCC deivice of this board a simple test has been developed to communicate between two boards:

    - The UCC1 of first board is physically linked to UCC1 of the second board.

    - The software configuration of UCC1 and UCC2 of each board are identical.

    - UCC1 of first board send a byte. This byte is receive by UCC1 of second board which resend it on UCC2. UCC2 of first receive this byte and compare it with the sending one on UCC1.

Software board 1	Software board 2
Configure UCC1 to transmit	configure UCC 1 to receive
Configure UCC2 to receive	configure UCC 2 to transmit
Send Byte on UCC1
	Receive Byte on UCC1
	send this Byte on UCC2
Receive Byte on UCC2
Compare these bytes

Problem:

This test works fine when the baud rate value is sufficiently high to not use the div 16 bit of BRGC register(When this bit is enable, a supplementary division by 16 is added to reach the desired baud rate)

But for low baud rate (div16 bit is used), the sending byte from UCC1 of board 1 is correctly receive by UCC1 of board 2. But when the board 2 try to resend this byte on UCC2, it seems that the baud rate clock is not well initialized (or not well synchronized). So the byte received by UCC2 of board 1 is not correct.

Investigation done:

1) This board replace an old one with MPC860 controller. So we try to make this test by using the MPC8323 board as board 1 and MPC860 as board2. This test works fine.

So the problem is due to the MPC8323 board when a byte have to be sent on UCC2 whereas a byte has just been received on UCC1.

2) Only UCC1, UCC2 and UCC3 are designed on the board. We trying different configuration between these UCC but that change noting. The board fail to send a byte on a UCC channel when a byte has just been received on an others UCC channel.

3) We tried to perform this test with the same UCC. So after receiving the byte on UCC1, we reconfigured UCC1 for transmission (by writing on GUMR register). Then we send the receiving byte. It seems that the same problems happens.

4) We tried to compare UCC2 register before and after the receiving byte on UCC1 but the register value are identical.

5) On board2, we tried to completely configure UCC2 after receiving the byte on UCC1. On board 2, the procedure test is:

   - Configure UCC1 and wait for to receive byte from UCC1 of board1.

   - When the byte is receive, completely configure UCC2 : stop it (on GUMR register), configure all registers and start it for transmission(GUMR register).

   - Transmit the receiving byte on UCC2

Software board 1	Software board 2
Configure UCC1 to transmit	configure UCC 1 to receive
Configure UCC2 to receive
Send Byte on UCC1
	Receive Byte on UCC1
	configure UCC 2 to transmit
	send this Byte on UCC2
Receive Byte on UCC2
Compare these bytes

This test works fine for all baud rate. But we want to understand why the test fail when the UCC2 configuration is done before receiving byte on UCC1.

Questions:

Is this a known issues?

Is there an issues about low baud rate (when div 16 bit is activated)? That could explain our problem ?

Do you have some UCC application which perform this kind of test for low baud rate?

Thanks for your help,

Mathieu

[alexander_yakov]

UCC supports several communication protocols - which protocol you are using?

Have a great day,
Alexander
TIC

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

[mathieuguithon]

Hi Alexander,

Thanks for your fast response.

Sorry I forget to specify that our test are performed for several configuration (baud rate, parity, data bit number and stop bit number) to correctly validate our board but the UCC device is always configured for QMC protocol (Slow protocol).

Thanks you,

Mathieu

[alexander_yakov]

Ok. How you connect two devices together physically?

[mathieuguithon]

Hello,

I am not in my office this week so I can't give you the correct pin connection.

As I remember, we use not crossed cable to connect UCC1 pins with UCC2 pins.

I will give you more information about when I come back to my office.

But as the test works for high baud rate, that means the pin connection is correct. Is it true ?

Or some pins connection can works for high baud rate and not for low baud rate ?

Thanks for your help,

Mathieu

[alexander_yakov]

There is no known issues related to DIV16 activated, in device errata I see only one errata related to BRG - it can potentially have spikes for odd division factors greater than 3. One of workaround for this errata is to use odd division factors only with DIV16 enabled, so I do not think this errata is directly related to your case.

[mathieuguithon]

Hello Alexander,

Thanks for your response. 

I performed some test where the BRG value is odd when the DIV16 bit is enable. But that change nothing and my problem still remains.

Moreover the using pins seems to be good. Our drivers configure the CPPAR1A and CPPAR2A registers to use the correct pins (table 3-11 of the reference manual of MPC8323)

For UCC1:

PA0 as SER1_TxD

PA4 as SER1_RxD

PA12 as SER1_RTS

and for UCC2 :

PA18 as SER2_TxD

PA22 as SER2_RxD

PA30 as SER2_RTS

Do you have some example which perform this kind of ping-pong communication between two UCC device of the same MPC8323 controller for example?

If yes, is this example works for low baud rate ?

If yes, can you send me its?

Thank for your help,

Mathieu