• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 97 subscribers
  • Views 541 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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 on OMAP-L137 (DMA resp. Free data format mode)

Frank
Intellectual 985 points
Other Parts Discussed in Thread: OMAP-L137

Hello,

I've a couple of questions related to the I2C on the OMAP-L137.
On the ARM side of the OMAP the following version are used:
- DSP/BIOS Version: 6.21.03.21
- CCS Version          : 4.1.3.00038

In december a new user guide "TMS320C674x/OMAP-L1x Processor Inter-Integrated Circuit (I2C) Module UG (Rev. B)" has been released by TI (sprufl9b).
In addition to the previous version the I2C DMA Control Register (ICDMAC) was added.
The new register has two bits (TXDMAEN/ RXDMAEN), value after reset is "1" for each bit, which means: DMA transmit/receive event is enabled.
Furthermore the description (see section 3.25) for both bits state: Always set this bit to 1.
Q1: Why must these bit always be set to "1"?
Q2: What happens if these bits were set to "0"?

Another item I like to address:
In our application a device is connected via IC2 as slave, the OMAP-L137 (ARM) is the I2C master.
To read a byte out of this device the following sequence must be performed:


START - write device addr (8 bit, e.g. 0x50) - SACK - write instruction (8 bit, e.g. 0x92) - SACK - read data from device (8 bit) - MACK - STOP

START: Start Condition
SACK : ACK from Slave
MACK : Ack from Master
STOP : Stop Condition
 
I tried to use the "Free data format mode" and it looks, that I cannot read data from the slave device.
Scope measurements showed, that the I2C device on the OMAP stops sending out clock singal after transmitting the first two bytes (ICCNT was set to 2).
I got only  two interrupts in ICIVR:
- Transmit-data-ready interrupt (ICXRDY), after the first byte is transmitted
- Register-access-ready interrupt (ARDY), after the second byte is transmitted

Experimental I tried to transmit 3 bytes to extend the clock signal, however then I got an Arbitration-lost interrupt (AL) in ICIVR and
the I2C Data Receive Register (ICDRR) does not contain the expected value.

Section 2.6.3 in sprufl9b states "... and the direction of the data must be constant throughout the transfer."
Q3: Does this statement mean that I can not perform the above sequence (as the TRX bit of ICMDR is changed from transmitter mode to receiver mode)?
Q4: Any ideas how to accomplish the above sequence on the OMAP-L137 resp. what could be wrong?

Thanks,
Frank

  • 0
    TI__Mastermind 27585 points

    Q1: Why must these bit always be set to "1"?
    This just enables the DMA events being sent to the system, as described. If DMA is not used then these can be disabled.


    Q2: What happens if these bits were set to "0"?
    A negligible amount of power can be saved by setting these to "0".

    Q3: Does this statement mean that I can not perform the above sequence (as the TRX bit of ICMDR is changed from transmitter mode to receiver mode)?
    The customary sequence that most devices support is START - device addr (W) - SACK - write instruction - SACK - START - device addr (R) - SACK - read data - MACK -STOP
    Can you verify that your device does not support this sequence?

    Q4: Any ideas how to accomplish the above sequence on the OMAP-L137 resp. what could be wrong?
    The best solution would be to try the sequence given in Q3, using the repeated start.

    Jeff

  • 0 in reply to jc-ti
    Intellectual 985 points

    Hello Jeff,

    if DMA could also be disabled, it would be nice to have this also described in sprufl9b.
    The sentence "Always set this bit to 1" is confusing me.

    Coming back to questions Q3 and Q4.
    The device does not support your described sequence. Have a look at the following data sheet:

    http://www.intersil.com/data/fn/fn8192.pdf

    Again, can my described sequence be implemented for the I2C on the OMAP-L137 without using bit banging (maybe by using the free data format)?

    Thanks,
    Frank

  • 0 in reply to Frank
    TI__Mastermind 27585 points

    I checked the datasheet and noticed that your device is a "2-wire" interface, which is not "I2C" compliant. This means you will have to use the free data format, since the other modes only support 7 or 10-bit addressing.

    Since free data format mode is uni-directional, you would have to perform two separate transactions. Transmitting 3 bytes would cause arbitration loss on the 3rd byte, since the potentiometer will drive data back at the same time.

    Have you tried doing two free data transactions, where the first transaction is a 2-byte write, and the second transaction is a 1 or 2 byte read? Unfortunately at the end of the first transaction the controller will always insert a STOP condition, which is not the sequence described in the datasheet you sent. If this doesnt work your only option would be to bit bang as you suggested.

    Jeff

  • 0 in reply to jc-ti
    Intellectual 985 points

    Hello Jeff,

    it looks that bit banging is the solution.

    Thanks,

    Frank