• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 78 subscribers
  • Views 471 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430F2254: MSP430F2254 Another workaround of Errata "USCI 35"

Cruijff
Expert 2760 points
Part Number: MSP430F2254

Hi community member,

My customer is considering the following problems and workarounds.
The contents are as follows.
Please tell me about two Questions.

"phenomenon"

Under the (repeat) start condition of I2C master mode,RESTART is not issued for the following conditions.
· Clock rate: 84 kHz
· ACK before 2nd byte from START Condition Clock stretch is 40us.

Question 1. Do you think this phenomenon applies to Errata's "USCI35"?

 

"Improvement measures"

The symptoms were improved by the following two methods.

(1) When changing the clock rate to 48kHz, the phenomenon does not occur. (From Workaround of USCI35)
(2) Change ACK before clock stretch of 2nd byte from START condition.

  •             40us ⇒ 100us

Question 2. Is the improvement plan of (2) effective?

My customers already introduced MSP430F2254 I2C master mode(repeated start), but fearing that changing the clock rate adversely affects the own entire system.
If (2) is valid, my customers think that they want to incorporate it.

Please let me know some advice!

Best regards.
Cruijff

  • 0
    TI__Mastermind 49692 points
    Hello,

    This issue does seem to stem from the USCI35 errata. Option 1 is the recommended fix, and I would not recommend changing ACLK dynamically, since it could negatively affect other things in the system if they depend on ACLK.

    Regards,

    James

    MSP Customer Applications
  • 0 in reply to James Evans
    Expert 2760 points

    Hi James,

    Thank you for your reply!

    I understood that is due to errata in USCI 35.

    > and I would not recommend changing ACLK dynamically, since it could negatively affect other things in the system if they depend on ACLK.

    I will supplement it as Option 2 may not be conveyed correctly.
    The countermeasure method is as follows.

    Set the time from sending data to sending the next Start Conditions (Restart Conditions) from 40 μs to 100 μs.
    Especially CLK is not changed.
    Change at software system level.

    It is an image like the following.

    Is this method effective as a countermeasure?

    please confirm.
    Cruijff

     

  • 0 in reply to Cruijff
    TI__Mastermind 49692 points
    Hello Cruijff,

    While what you're saying makes sense conceptually, I would hesitate to recommend Option 2 over our recommended workaround. My concern would be related to corner cases where a fixed value of 100us wouldn't work entirely due to device-to-device differences. The customer is free to implement this method if they are comfortable taking this risk, but I recommend Option 1 to ensure correct operation across all devices.

    Regards,

    James

    MSP Customer Applications
  • 0 in reply to James Evans
    Expert 2760 points
    Hi James!

    I understood Option 1 be recommend.
    Thank you for your reply!

    Cruijff

**Attention** This is a public forum