Questions about the DUART Errata(A-004737)

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

Questions about the DUART Errata(A-004737)

跳至解决方案
1,639 次查看
dongyang626
Contributor I

Dear all,

We have four questions about the DUART Errata (A-004737) in the ‘P2020CE Rev. CC, 01/2016’ document (see the attachment), and we used P2010 CPU.

1. what the ‘Previously DUART 1‘ means?

     only the UART1 has this problem and UART2 will be OK?

2. besides the software, Does the hardware can generate the ‘break signal’ also? If yes, What's the scenario?

3. In the Workaround section: ‘This workaround requires that the break signal be at least 2 character-lengths in duration’. 
How we can know the break signal will durative 2 character-lengths?

Thanks a lot.

标记 (2)
0 项奖励
1 解答
1,342 次查看
Pavel
NXP Employee
NXP Employee

Correct is the following:

If ULSR is read and ULSR[BI]=1, read URBR and clears the ULSR[DR] bit. Then delay at least 1 character period. Then read URBR again and clears the ULSR[DR] bit


Have a great day,
Pavel Chubakov

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

在原帖中查看解决方案

6 回复数
1,343 次查看
Pavel
NXP Employee
NXP Employee

Correct is the following:

If ULSR is read and ULSR[BI]=1, read URBR and clears the ULSR[DR] bit. Then delay at least 1 character period. Then read URBR again and clears the ULSR[DR] bit


Have a great day,
Pavel Chubakov

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

1,342 次查看
Pavel
NXP Employee
NXP Employee

This workaround can be used if for break signal length is one character length.

 

Usually software produces break signal.


Have a great day,
Pavel Chubakov

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

0 项奖励
1,341 次查看
dongyang626
Contributor I

Thanks for your reply. I'm trying to make my point more clear. I suppose to do like this.


For example, the break single has 5 character-lengths in duration. accroding to erratum A-004737, ULSR[BI] and ULSR[DR] bits
shall be set another 4 times after the first ULSR[BI] and ULSR[DR] clear. i.e, ULSR[BI] and ULSR[DR] shall be set 5 times for 5 character-lengths in duration.


I read URBR as a dummy character each time ULSR[BI] and ULSR[DR] are set, until no ULSR[BI] is detected.

Is anything wrong my understanding? Thanks.

0 项奖励
1,341 次查看
dongyang626
Contributor I

Thanks for your reply. I'm trying to make my poring more clear. I suppose to do like this:

For example, the break single has 5 character-lengths in duration. accroding to erratum A-004737, ULSR[BI] and ULSR[DR] bits shall be set another 4 times after the first ULSR[BI] and ULSR[DR] clear.

i.e, ULSR[BI] and ULSR[DR] shall be set 5 times for 5 character-lengths in duration.

I read URBR as a dummy character each time ULSR[BI] and ULSR[DR] are set, until no ULSR[BI] is detected.

Is anything wrong my understanding? Thanks.

0 项奖励
1,341 次查看
Pavel
NXP Employee
NXP Employee
  1. This erratum was named in previous revision on the P2020 errata list as erratum DUART 1.
  2. The P2020 DUART can send break. See description of the DUART_ULCRn[SB] bit.
  3. This workaround is work if there is break signal during at least 2 character-lengths in duration. If break signal assertion length is single character-length, this workaround is not needed.


Have a great day,
Pavel Chubakov

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

0 项奖励
1,341 次查看
dongyang626
Contributor I

Thanks for your answer.

I still have further question based on your answer.
Since the 'break signal' is infrequently in our system, and the length is also unknown to us. Can we handle the 'break signal' like the following?
Read URBR as a dummy character once ULSRn[BI] is set, then clear the ULSR[BI] bit (ULSR[DR] will also be cleared by the action).
In other words, we don't care about the times of the ULSRn[BI] triggered for a single 'break' assert, but just ignore the character once ULSRn[BI] is set.
If ULSRn[BI] and ULSRn[DR] are set at the same time, I assume the way will work.

BTW, Does 'break signal' only be able to be send by software? Can it be introduced by any hardware condition, such as physical line broken?


Thanks again. :smileyhappy::smileyhappy:

0 项奖励