• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 39 subscribers
  • Views 1186 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.

TIDA-00524: I2C communication problem after removing some sensors

Aladdin
Prodigy 150 points
Part Number: TIDA-00524
Other Parts Discussed in Thread: TMP112, MSP-FET, RF430CL331H, RF430CL330H,

Hello everyone,

I am trying to build the data-logger with the temperature sensor only using TIDA 00524 as a reference design (www.ti.com/.../TIDA-00524). In other words, the hardware that I have built is exactly the same as TIDA 00524, but without the light and humidity sensors. My programming skills are limited, and I wanted to adjust the cold chain CCS code to make it work with my hardware. I excluded the "# include" lines for the humidity and light sensors from the original code in mcu.h file. Also, I replaced the available modes in main.c file to temperature only. I tested my code on the original TIDA 00524 hardware and it worked. After that I used MSP-FET to upload my code to my hardware. After troubleshooting I found out that in my hardware the code getsstuck on the following line in TMP112.c file :

while(!(UCB0IFG & UCBCNTIFG)); 

I think I am having a problem with I2C communications, because I removed 2 sensors from the bus. I can not even read the NFC signal from my hardware. 

P.S.

The original code can be found here : http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=tidcb42&fileType=zip

You can find my modified code enclosedMyCode.zip

  • 0
    TI__Mastermind 32395 points
    Hello Alaaedden,

    Thanks for using our reference design. We are looking into this currently for root cause.

    Sincerely,
    Peter Iliya
    Current Sensing Applications
  • 0
    TI__Mastermind 43975 points
    Hi Alaaedden,

    UCB0IFG refers to the interrupt register for the eUSCI module that is being used to perform I2C communication. This register is described on page 855 of the MSP Family User's Guide. www.ti.com/.../slau367o.pdf

    Since communications take place at a much slower rate than the CPU core frequency, these modules are used to perform limited communication actions while the CPU is busy doing other things. When the module is done with its task, it alerts the CPU that it needs attention by raising an interrupt. The CPU then decides what task, if any, to assign to the module next. This happens several times within one serial transaction. If the interrupt is not serviced correctly, or if something unexpected happens in the module, the communication can stall and never complete successfully.

    In your line of code, the CPU is waiting for the module to complete a task. It does this by continuously checking the contents of the interrupt register in a loop. This is a crude way of interacting with the module, because the CPU is not able to perform other actions or turn itself off to conserve power while the module is working on its task. If your CPU always gets stuck on this line of code, it means the interrupt it was expecting from the module never came.

    UCBCNTIFG is the interrupt that the CPU is waiting for in your line of code. This interrupt is described on the aforementioned page 855 and in further detail on page 836. It seems to be triggered by a certain number of bytes transmitted. I've not seen this feature used before, so I won't be able to answer further questions about it.

    Questions about MSP430 Software should be directed to the MSP430 Forum on E2E. e2e.ti.com/.../ You can check out other examples of I2C communication in the Resource Explorer within CCS. I highly recommend that you also study the diagrams on page 830 and 832 to get a better understanding of the transaction sequence and interrupts associated. This will help you understand the 'tasks' that the eUSCI module is performing.

    All that aside, I suggest that you start your debugging by connecting an oscilloscope or logic analyzer to your I2C bus. You should be able to see clearly where the transaction begins and aborts. If you can provide these waveform images, I can answer your questions about I2C as it pertains to TMP112 in the Temperature Sensors Forum. e2e.ti.com/.../f

    Thanks,
    Ren
  • 0 in reply to Ren Schackmann
    Prodigy 150 points
    Actually I rebuild my whole hardware to be exactly the same as TIDA 00524, and I am still not managing to make it work. The only different between TIDA 00524 and my hardware is that I used RF430CL330H instead of RF430CL331H. Is this what causing the problem in the code? and if this is the case , how I can solve it

    Thank you
  • 0 in reply to Aladdin
    TI__Mastermind 43975 points
    Hi Alaaedden,

    The RF430 does share I2C Bus with the TMP112 in the TIDA-00524. It's plausible that a mistake with the RF430 could interfere with the operation of the I2C Bus and operation of TMP112.

    You should direct any questions about the RF430 to the NFC/RFID Forum. e2e.ti.com/.../f

    Thanks,
    Ren
  • 0 in reply to Ren Schackmann
    Prodigy 150 points
    I figure out that I did two mistakes. One that I used RF430CL330H instead of RF430CL331H. Because in the schematics of TIDA00524 there was a mistake in the document. My second mistake, that I flipped the I2C buses, and it was really hard to recognize it after I had everything built.
    Thanks a lot for your help, that you lead me to focus on the RF430CL330H.