SLAZ101AB October   2012  – May 2021 CC430F6135

 

  1. 1Functional Advisories
  2. 2Preprogrammed Software Advisories
  3. 3Debug Only Advisories
  4. 4Fixed by Compiler Advisories
  5. 5Nomenclature, Package Symbolization, and Revision Identification
    1. 5.1 Device Nomenclature
    2. 5.2 Package Markings
      1.      RGC64
    3. 5.3 Memory-Mapped Hardware Revision (TLV Structure)
  6. 6Advisory Descriptions
    1. 6.1  ADC24
    2. 6.2  ADC25
    3. 6.3  ADC27
    4. 6.4  ADC29
    5. 6.5  ADC42
    6. 6.6  ADC69
    7. 6.7  AES1
    8. 6.8  BSL7
    9. 6.9  COMP4
    10. 6.10 COMP10
    11. 6.11 CPU18
    12. 6.12 CPU20
    13. 6.13 CPU21
    14. 6.14 CPU22
    15. 6.15 CPU23
    16. 6.16 CPU24
    17. 6.17 CPU25
    18. 6.18 CPU26
    19. 6.19 CPU27
    20. 6.20 CPU28
    21. 6.21 CPU29
    22. 6.22 CPU30
    23. 6.23 CPU31
    24. 6.24 CPU32
    25. 6.25 CPU33
    26. 6.26 CPU34
    27. 6.27 CPU35
    28. 6.28 CPU39
    29. 6.29 CPU40
    30. 6.30 CPU46
    31. 6.31 CPU47
    32. 6.32 DMA4
    33. 6.33 DMA7
    34. 6.34 DMA8
    35. 6.35 DMA10
    36. 6.36 EEM8
    37. 6.37 EEM9
    38. 6.38 EEM11
    39. 6.39 EEM13
    40. 6.40 EEM14
    41. 6.41 EEM16
    42. 6.42 EEM17
    43. 6.43 EEM19
    44. 6.44 EEM23
    45. 6.45 FLASH29
    46. 6.46 FLASH31
    47. 6.47 FLASH37
    48. 6.48 JTAG20
    49. 6.49 JTAG26
    50. 6.50 JTAG27
    51. 6.51 LCDB1
    52. 6.52 LCDB3
    53. 6.53 LCDB4
    54. 6.54 LCDB5
    55. 6.55 LCDB6
    56. 6.56 MPY1
    57. 6.57 PMAP1
    58. 6.58 PMM8
    59. 6.59 PMM9
    60. 6.60 PMM10
    61. 6.61 PMM11
    62. 6.62 PMM12
    63. 6.63 PMM14
    64. 6.64 PMM15
    65. 6.65 PMM17
    66. 6.66 PMM18
    67. 6.67 PMM20
    68. 6.68 PORT15
    69. 6.69 PORT16
    70. 6.70 PORT17
    71. 6.71 PORT19
    72. 6.72 PORT21
    73. 6.73 RF1A1
    74. 6.74 RF1A2
    75. 6.75 RF1A3
    76. 6.76 RF1A5
    77. 6.77 RF1A6
    78. 6.78 RF1A8
    79. 6.79 RTC3
    80. 6.80 RTC6
    81. 6.81 SYS16
    82. 6.82 TAB23
    83. 6.83 UCS6
    84. 6.84 UCS7
    85. 6.85 UCS9
    86. 6.86 UCS10
    87. 6.87 UCS11
    88. 6.88 USCI26
    89. 6.89 USCI30
    90. 6.90 USCI31
    91. 6.91 USCI34
    92. 6.92 USCI35
    93. 6.93 USCI39
    94. 6.94 USCI40
    95. 6.95 WDG4
  7. 7Revision History

USCI30

USCI Module

Category

Functional

Function

I2C mode master receiver / slave receiver

Description

When the USCI I2C module is configured as a receiver (master or slave), it performs a double-buffered receive operation. In a transaction of two bytes, once the first byte is moved from the receive shift register to the receive buffer the byte is acknowledged and the state machine allows the reception of the next byte.

If the receive buffer has not been cleared of its contents by reading the UCBxRXBUF register while the 7th bit of the following data byte is being received, an error condition may occur on the I2C bus. Depending on the USCI configuration the following may occur:

1) If the USCI is configured as an I2C master receiver, an unintentional repeated start condition can be triggered or the master switches into an idle state (I2C communication aborted). The reception of the current data byte is not successful in this case.
2) If the USCI is configured as I2C slave receiver, the slave can switch to an idle state stalling I2C communication. The reception of the current data byte is not successful in this case. The USCI I2C state machine will notify the master of the aborted reception with a NACK.

Note that the error condition described above occurs only within a limited window of the 7th bit of the current byte being received. If the receive buffer is read outside of this window (before or after), then the error condition will not occur.

Workaround

a) The error condition can be avoided altogether by servicing the UCBxRXIFG in a timely manner. This can be done by (a) servicing the interrupt and ensuring UCBxRXBUF is read promptly or (b) Using the DMA to automatically read bytes from receive buffer upon UCBxRXIFG being set.

OR

b) In case the receive buffer cannot be read out in time, test the I2C clock line before the UCBxRXBUF is read out to ensure that the critical window has elapsed. This is done by checking if the clock line low status indicator bit UCSCLLOW is set for atleast three USCI bit clock cycles i.e. 3 X t(BitClock).

Note that the last byte of the transaction must be read directly from UCBxRXBUF. For all other bytes follow the workaround:

Code flow for workaround

(1) Enter RX ISR for reading receiving bytes
(2) Check if UCSCLLOW.UCBxSTAT == 1
(3) If no, repeat step 2 until set
(4) If yes, repeat step 2 for a time period > 3 x t (BitClock) where t (BitClock) = 1/ f (BitClock)
(5) If window of 3 x t(BitClock) cycles has elapsed, it is safe to read UCBxRXBUF