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.

I2C - Master Read/Write only Slave Address, with no data

Other Parts Discussed in Thread: TM4C123GH6PM

I'm working with a Medical Specialties Pressure Sensor (low power configuration) that requires a zero-data byte write/read to the I2C interface in order to wake up and initiate an ADC measurement.


http://www.meas-spec.com/downloads/Interfacing_to_MEAS_Digital_Pressure_Modules.pdf

[Write_MR & Right_MR, on page 4]


In an email from TI's Technical Support I was told that this behavior is accounted for in the I2C Bus Specification, and that the TM4C123GH6PM which fully supports it, is thereby capable of this sort of transmission. The email however failed to answer my other question of how a zero-data byte read/write could be accomplished.

Another thread here mentioned a very similar MCU and issue being addressed. That concluded in a TI employee saying that is wasn't possible.
So that's 1:1 for Possible:Impossible.

I've read through the MCU's datasheet, and can't for the life of me find a way to induce the I2C peripheral of the MCU to output what the sensor needs. A data byte is always read/written, thereby confusing the sensor.

If anyone can help me out with getting this resolved, it'd be appreciated.

  • When all else fails - might you be able to, "Bit-bang" the MCU to create that, "zero-data byte write/read?"

    Upon waking the sensor - you may switch the MCU into its more normal/customary means of I2C operation.

    Suspect that this requires some experimentation with the values of pull-up resistors - unless you force your GPIO into "open drain" mode initially - while the bit-bang is, "in play."

  • Hello Tim,

    As I mentioned in that thread as well, Zero Data Byte Read/Write is not possible from the Master. Could you please the concerned TI Tech Support to contact me so that I can check why has this been mentioned?

    Other than that as cb1 has duly noted, bit-banging the IO's may be the other alternative.

    Regards
    Amit
  • Indeed I could, and the thought had crossed my mind. However the product I'm developing for has many tasks it needs to be juggling in the background. One key point in using the I2C interface was to remove the need for the processor to camp out and bit-bang.
  • Hey there Amit,

    Thanks for the confirmation. How do you suggest I discreetly connect you to the agent that emailed me earlier?
  • Hello Timothy,

    No need to be discrete. My full name is already here on the forum, so you can ask them to drop me an email with "I2C Single Zero Data Read/Write" as the subject so that my email flags it.

    Regards
    Amit
  • It is true that I could do that, so I'll keep that in mind. However I don't feel comfortable toggling the GPIO mode between modes at the 1kHz required for the product. Perhaps my unease is unfounded, but the product is medical in nature, and I'm working to keep things as stable as possible.
  • Timothy Schroeder said:
    remove the need for the processor to camp out and bit-bang.

    That "camping out" would be brief and then done with - would it not?   (unless you regularly want to toggle that sensor between, "wake/sleep.")

    Note that my suggestion was to (only) "bit-bang" while massaging out the (difficult) "wake" sequence!   You then switch to "plain vanilla" I2C operation.

    Should that "sleep" mode be dominant - and should each (brief) bit-bang session prove undesirable - perhaps the search for a less demanding sensor is indicated...

  • The low power design automatically returns the sensor to sleep after each measurement is taken. So for sampling I'd have to repeatedly switch between the GPIO and I2C mode.

    I'm currently in contact with an engineer at Measurement Specialties, and he's investigating if there are an options to avoid the zero-byte command. However if there isn't, then I will indeed be selecting a different sensor.

    At least now I can stop searching for the "magic register bit" to allow for 0-byte transmissions.
  • Our firm uses ARM MCUs from 4 different vendors - at least 2 "share" this vendor's inability to (easily) generate that 0-byte xmsn.

    Surely there must be a "free" sensor register (likely there are many) which may be employed to wake the sensor. Restricting that essential "wake" to so demanding a sequence seems very, "misguided."    Only justification I can imagine is a shorter duration transaction - saving your (likely) battery.

    Now that all facts are open/known - feel your pain - that "wake demand" borders upon an outrage...   (at least they should provide an alternative "wake.")