• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 30 subscribers
  • Views 754 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: ADS7142 Device Functional Modes

William Santos56
Prodigy 390 points
Part Number: TM4C1294NCPDT
Other Parts Discussed in Thread: ADS7142

I have attached word documents with each of the .c files I am currently using to do the single register read and write functions.  The one labeled “working” yields the correct 0x03 data from the register 0x20 on the analyzer as shown below:

The analyzer screenshot below is from my using pre-declared functions in main (which is currently not working):

What seems to be driving the error in the non-working code is the presence of UART statements that are highlighted on page 7 of the “working” document.  One of those two statements is providing the processor or core with some sufficient delay or condition for the data to be transmitted and received correctly. 

For reference, I’ve attached the ADS7142 datasheet and TM4C1294NCPDT datasheet.  In the code, I am simply reading the reset value of the AUTO_SEQ_CHEN (0x20) register: its reset value is (0x03).  The Single Register Read opcode is 0x10.  Your help is greatly appreciated

SingleRegisterRead_working.docxSingleRegisterRead_notworking.docxads7142.pdftm4c1294ncpdt.pdf

  • 0
    TI__Guru*** 135355 points
    Hi William,

    Preliminary question after reading your post + code, for the example that is working, can you try commenting out the sending of UART data so we can see if it works or fails when the UART isn't adding that delay from slave address set to read register?
  • 0 in reply to Ralph Jacobi
    TI__Prodigy 390 points

    Ralph,

    The following code is modified so that all of the UART statements are removed except for one of the two UART statements required to receive expected power-on reset data from the register map of the device.  I have attached this modified code and highlighted the UART statement causing the anomaly.  

    So to elaborate, Figures 49 and 50 in the ADS7142 datasheet are the i2c transactions we are developing with this code.  I'd recommend printing pages 28 and 29 for reference.  Pages 1290-1293 of the TM4C1294NCPDT datasheet contain the Host Transmit/Receive of Single or Multiple Data Bytes.  To my knowledge, the error service processes are missing from the i2c.c source files but I do believe this building block of code can be completed without implementing the error-checking/error-service.

    I will post results of another reset value for a different register (0x2C) to verify the current code configuration.

    After condensing this code into functions to call from main I will provide an update: but the UART anomaly is so weird!

    Best Regards and Wishes,

    Will

    ADS7142RegisterMap.docxi2c.c.docxi2c.h.docx

    SingleRegisterRead_functioningbutwithuartinthere(justtheoneline).docx

  • 0 in reply to William Santos56
    TI__Prodigy 390 points
    For hardware, I am using the TM4C1294NCPDT Launchpad and ADS7142 boosterpack connected as shown on the launchpad product page with a salae logic analyzer to debug (any analyzer with sample speed upwards of 100-200 kHz should do, I am running I2C at the standard 100 kHz.

    Will
  • 0 in reply to William Santos56
    TI__Guru*** 135355 points

    Hi William,

    William Santos56 said:
    So to elaborate, Figures 49 and 50 in the ADS7142 datasheet are the i2c transactions we are developing with this code.

    Do you have any fully developed examples which you can share the Saleae captures with me so I have a baseline to compare with? Can be from another MCU, just want to see what the expected working I2C signals should appear as.

    Also, I have Saleae myself, so it would actually be very helpful to include the Saleae capture files in your posts either instead of or in addition to the images. Also I'd prefer getting .c files rather than .docx files as all I am doing is copy pasting them into Notepad++ so I can read the code cleanly...

    Usually if the UART delay causes something to work, then either it is going too fast (which is not the case here, as you are using 100kbps which is good!), or the slave device needs more time to reply... going through full Saleae captures for the ADS7142 working correctly as well as the failure with TM4C will help me understand any possible timing issues that the I2C driver could be generating, as well as look at the stop/start conditions and when they are being triggered for each case (which I can't fully see for the working example based on your screenshots).

  • 0 in reply to Ralph Jacobi
    TI__Prodigy 390 points

    Ralph,

    I had found that, according to the errata, inserting a SysCtlDelay(100) after each I2CMasterControl() function call resolved the issue here but I am getting a different problem now.  I cannot attach .logicdata files from the salae analyzer as the forum does not accept this file extension.  Thanks

    Regards,

    Will

  • 0 in reply to William Santos56
    TI__Guru*** 135355 points
    Hello William,

    Not sure if hiding them in a .zip would get around this issue. Anyways, usually I'd suggest dropbox or google drive but since we are both TI, just email me the file?

    Anyways, if you want to continue the discussion of the new issue in your new thread then I don't mind, I hadn't realized the issues were unrelated. Just mark your prior answer for resolution so we can close this one out.

    For any future readers, the errata referred to would be I2C#08.