• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 660 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.

TM4C1294NCPDT: Interfacing with LDC1614 Using I2C

Abdullah Abdulghany
Prodigy 70 points
Part Number: TM4C1294NCPDT
Other Parts Discussed in Thread: LDC1614

Hello, I'm interfacing with LDC1614 using I2C module in Tiva C Tm4c1294NCPDT, There is something wrong I can't understand in I2C module, when I was polling in Busy bit in I2CMCS Register, the bit doesn't even changed when I was debugging, I resolved it with software delay but it's wrong I guess, I wanna use polling in the right bit in the register cause without this delay the module would be too fast that the sensor can't write or read 

short story long: I use Burst mode command as I senf 16-bit data twice (8-bit per command), in line 78 as an example, The Busy bit in I2CMCS doesn't change so there is no polling, I followed the flowchart in the datasheet, but it didn't work

P.S: Here is a piece of code of my LDC_write Function 

  • 0
    TI__Guru**** 191906 points

    Hi Abdullah,

      Can you try in each I2CMasterBusy()

    replace:

    while (I2CMasterBusy(I2C0_BASE) == true); 

    with 

    while (!I2CMasterBusy(I2C0_BASE) == true);  // Add this line.  

    while (I2CMasterBusy(I2C0_BASE) == true);   // Keep this line after the above line.

  • 0 in reply to Charles Tsai
    Prodigy 70 points

    what is the use of this line, The BUSY bit is 0 and does not change  while the I2CMCS register has 0x00000003;

  • 0 in reply to Abdullah Abdulghany
    TI__Guru**** 191906 points

    Hi,

      There is a race condition in the I2C hardware. Please use the below code for example. The third line is supposed to wait until the I2C master is not busy before proceeding to the subsequent code. However, with the race condition, the third line will immediately fall through. The purpose to add the second line is to first wait until the busy flag get set and then wait further for the busy flag to get clear.  

    I2CMasterControl(I2C7_BASE, I2C_MASTER_CMD_BURST_RECEIVE_START); // Start  a burst mode read

    while(!I2CMasterBusy(I2C7_BASE)) // Wait until the busy flag is set
    {
    }

    while(I2CMasterBusy(I2C7_BASE)) // Wait until the busy flag is clear
    {
    }

  • 0 in reply to Abdullah Abdulghany
    Prodigy 70 points

    I've Put the line you advised yesterday, it didn't work and the code stuck in this polling ? My problem is timing and not knowing the required bit to check ? 

  • 0 in reply to Abdullah Abdulghany
    Prodigy 70 points

    I've record the debugging session, you can view it through this Drive link: drive.google.com/open

  • 0 in reply to Abdullah Abdulghany
    TI__Guru 72500 points

    Sorry, but file share systems are blocked for me here at work. I will check to see if I can access it from home this weekend.

  • 0 in reply to Bob Crosby
    Prodigy 70 points

    no problem I tried to prove a point that the line of code of charles didn't work from me and I was wondering if there is no problem to use a small delay before the polling like the one in the picrture, after I used this delay the sensor interfaced correctly and received & send the data I wrote 

    is it correct or there is a better way ?

  • 0 in reply to Abdullah Abdulghany
    TI__Guru 72500 points

    There is no problem using the simple delay before polling for the busy bit to be clear. The root cause is that the TM4C1294 device can execute the first read of the poll, before the I2C can set the busy bit. The delay prevents that. Some customers do not like the delay because they are concerned that if the delay is too big they are wasting time. My only concern is why did the solution Charles proposed not work? If there is some intermittent delay, perhaps caused by an interrupt, the method Charles suggested may fail. We have discussed this very issue here at TI. I feel the perfect solution has remained elusive. Bottom line, a short delay before the calling I2CMasterBusy() should work just fine.

  • 0 in reply to Bob Crosby
    Prodigy 70 points

    "My only concern is why did the solution Charles proposed not work? If there is some intermittent delay, perhaps caused by an interrupt, the method Charles suggested may fail.", I didn't understand your concern, Excuse my little knowledge, The charles code caused the program to stuck in this line 

    while(!I2CMasterBusy(I2C7_BASE)) // Wait until the busy flag is set
    {
    }

    so I couldn't get reading from LDC1614, when I was debugging it step by step it worked but wrong data,So I figured it's because of my code probably. 

    Last inquiry: is there any example for I2C for EEPROM for example cause I didn't see it in the driver of 1294XL

  • 0 in reply to Abdullah Abdulghany
    TI__Guru 72500 points

    Don't worry about the concerns of using the "while(!I2CMasterBusy())" loop. Using the short delay should work. Optimization levels, clock ratios and even code alignment can affect the time critical relationship between the CPU and the I2C. Just make sure your delay is long enough to work with the highest level of optimization you use and you should be fine.

    I do not have any I2C EEPROM examples. I don't see that requested often. Probably because of the availability of emulated EEPROM on chip.