• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 2 answers
  • Subscribers 78 subscribers
  • Views 1661 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.

MSP430FR5969: eUSCI I2C - Zero-Byte non-blocking I2C read

Quinn Mikelson
Prodigy 190 points
Part Number: MSP430FR5969

Hello,

I've recently been working on an I2C driver interface for one of my company's products. The control firmware is built on an MSP430FR5969 and utilizes eUSCI B0 configured for I2C.

I've put a great amount of effort into designing a high-speed non-blocking ISR state machine and so far it is entirely stable up until about 500KHz. 

The firmware is configured for master only, and hardware configuration has been verified by our electrical engineering team.

The current issue is that I see the same Receive behavior no matter how the first byte transaction is configured. If I assert a UCTXSTT and react on a UCRX0IFG I receive two bytes, this I am aware is as intended. If I assert both (UCTXSTT | UCTXSTP) at the same time, even before enabling the I2C lines or the interrupts, I always receive one byte after a slave ACK. The User guide mentions that slave data is received following an ACK only if the UCTXSTT is not set; my question is, why am I still clocking in another byte? We have equipment that reacts differently to both Zero-Byte READs *and* WRITEs. How can I implement an entirely non-blocking zero-byte READ with the eUSCI module?

Also, are there any more detailed references on non-blocking I2C with the eUSCI? The TI examples I've been able to find have been severely limited and lack edge-case and error-condition logic. A FSM diagram would be incredible!

  • 0
    TI__Expert 7530 points
    Hi Quinn,

    I'll get a setup to reproduce what you are seeing and then we can dig into it a bit more. Just to clarify, does the dual-receive issue happen at all I2C clock rates, or only when you get to 500kHz? The I2C CLK max specification on this device is 400kHz.

    Regards,
    Walter
  • 0 in reply to Walter Schnoor
    Prodigy 190 points
    I always receive at least one byte when asserting both (UCTXSTT | UCTXSTP) no matter the speed, all testing is being performed at 50KHz
  • 0 in reply to Quinn Mikelson
    TI__Expert 7530 points

    Thanks for the clarification, Quinn.

    Walter

  • 0 in reply to Walter Schnoor
    TI__Expert 7530 points
    I'd like to clarify one more thing here.

    When you mention zero-byte read and zero-byte write, are you attempting to simply send a START -> ADDR/RW -> STOP sequence, with no data actually transmitted at all? In other words, you are just addressing a slave, getting the ACK, and then killing the transaction?

    Or, are you running a START -> ADDR/RW-BYTE0 -> STOP sequence, where you read/write just a single byte after the addressing occurs?

    Regards,
    Walter
  • 0 in reply to Walter Schnoor
    Prodigy 190 points

    After pouring over user guides, forum posts, and datasheets, I expected START -> ADDR/RW -> STOP for *both* Read and Write bits,

    Write works as expected, but read *always*  results in your second case: START -> ADDR/RW-BYTE0 -> STOP. If I set STT and STP simultaneously I always receive one byte. Right now we're looking into two options. 

    1. Turn all zero-byte reads into zero-byte writes

    2. Block all zero-byte reads.

    Ideally we want to implement void reads and void writes 

  • 0 in reply to Quinn Mikelson
    TI__Expert 7530 points
    Quinn,

    I dug into this a bit deeper and I do not believe there is a way to implement a hardware void read using the eUSCI. You would need to do this manually by controlling the IO.

    This is not a commonly supported I2C use-case, and can actually be tricky if the slave device doesn't know exactly how to handle it. From an I2C spec point of view, when in master receiver mode there should be a master NACK before the assertion of the STOP. This is to prevent a conflict, as the slave could hold SDA on the next clock after the ADDR/RW SLAVE ACK if the slave wants to output a low value for the MSB of what would be read next. In that case, the master wouldn't be able to give a stop condition and you can hang the bus. Thus it is good practice to always run the dummy read with the master receiver sending the NACK followed by the STOP. In the master transmitter case the slave device doesn't take control of SDA on the next clock after the ADDR/RW slave ACK, so it's possible to safely send the STOP at that point.

    Out of curiosity, what is the need in this specific case for the zero byte read? Do you have slave devices that require support for this behavior? If so I would like to know so that we can take this into consideration in the future. I must admit this is not a request I have come across in my experience, so it would be good to understand the requirements for the use-case.

    Community members, feel free to jump in as well and correct me if I am misinterpreting the Philips spec.

    Regards,
    Walter
  • 0 in reply to Walter Schnoor
    Prodigy 190 points

    Walter,

    Our EE team has designed a custom routing interface for our various communication interfaces. I2C is switched to different boards (each with identical slave address groups). The switching devices reconfigure themselves according to the address and R/W bit sent out, but are not true I2C slaves. These devices act as large multiplexers that pass through data to logic that further processes and routes I2C data.

    It seems that the hardware implementation was not thoroughly reviewed, as the designer has made the assumption that void reads and void writes were possible with the MSP430FR5969's eUSCI module. If there is absolutely no way to send a slave address and R/W NACK then we may have to review the design. We'd like to avoid having to reconfigure the eUSCI into GPIOs for every transaction as our process for approving post-fabrication software changes is incredibly lengthy.The GPIO solution has been discussed and is not ideal.

    I was also under the impression that the maximum I2C clock speed was 1/4 the MCLK frequency. Is this not true?

    Thank you,

    Quinn

  • 0 in reply to Quinn Mikelson
    TI__Expert 7530 points

    Hi Quinn,

    I'll do some additional digging to make sure, but right now I do not see a way to do a void read.  Void write is not a problem.

    Quinn Mikelson said:
    I was also under the impression that the maximum I2C clock speed was 1/4 the MCLK frequency. Is this not true?

    Do you have a link to the documentation that mentions this?  Below is the datasheet specification that clarifys the maximum I2C SCL frequency.

    Walter

  • 0 in reply to Walter Schnoor
    TI__Expert 7530 points
    Quinn,

    I wanted to close back out with you again. I can confirm that the eUSCI does not support hardware zero-byte reads, so this would in fact be a limitation for you. I checked with another expert on the eUSCI_B just to be sure. Also, as mentioned above, the SCL limit is 400kHz.

    Feel free to let me know if there is anything else I can help with.

    Regards,
    Walter

**Attention** This is a public forum