• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 2 answers
  • Subscribers 46 subscribers
  • Views 535 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TLC1518 Not performing one shot conversion using SPI

Joe7216
Prodigy 195 points
Other Parts Discussed in Thread: TLC1518

I'm just getting started interfacing to the TLC1518 over SPI from a PIC32 uC.  (SPI is configured for 16 bit mode)

The data sheet is either lacking, or I am interpreting it incorrectly.  Here are the issues I have:

I write the required 0xA000 first and then clear out the SPI input buffer

I write my CFR config (0xA004)  to the device and then clear out the SPI input buffer.

When I read the CFR I always get 0xX084.  The extra bit is the INPUT SEL bit.  I set it to NORMAL (0) but it comes back as PSEUDO DIFFERENTIAL (1).  I verified w/a scope both the write and read and can see I sent a 0 in that bit position and that the 1518 sent a 1 back.  Any idea why this is happening.

I then moved on to try a one shot conversion.  I am setup for a NORMAL conversion (Not extended....although I can't find in the data sheet how you select this option).  I am using the SCLK w/CS to perform the conversion.  I issue the 0x0000 command to perform a conversion on channel 0 and clear the SPI input buffer.  I see the EOC line go low at the end of the string of SCLKs, but it never goes back high.  The data sheet seems to imply it will go high when the CS goes high, but it does not.  What will cause it go to back to the high state?  I issue another 0x0000 command to try and read the converted data, but all I ever get is 0xFFF0 regardless of the voltage I apply to the input pin A0.

What am I missing (other than the data :-)?


Thanks,

Joe B.

  • 0
    TI__Expert 4405 points

    Joe,

    I am sorry about this delay in responding.

    Could you please confirm the state of the FS pin – are you holding it high, if not used in your design?

    How many clock cycles after the CS fall are you seeing the EOC/INT line go low?

    This looks like an issue with the interface signals or timing. Could you please share oscilloscope screenshot of the interface signals to debug this in detail?

    Regards,

    Sandeep

  • 0 in reply to Sandeep Kasargod
    Prodigy 195 points

    Thanks Sandeep.


    FS=PWDN=CSTART=1 (Not used)

    I am unable to provide screen captures b/c this board is a production board and I have no way to 'clip' to anything.  I verified the timing of the SPI bus and have the uC set to (CKE=1, CKP=SMP=0 on the PIC32MX795...I have attached a pdf that shows the representation of the timing during my write/read of the config register in both the 8-bit & 16-bit mode of the uC SPI).  The timing appears to be correct for the register write, and the sweep command.  I would assume it should be no different for the one-shot command. 

    The EOC line goes low after the 16th clock pulse of the one-shot command (last clock while CS is low).

    Joe B.


    LAC BenchTesting.pdf

  • 0 in reply to Joe7216
    TI__Expert 4405 points
    Joe,

    Thank you for your response.

    It looks like your design is split across multiple boards. Interface timings and signal integrity could get impacted by cabling and connectors. Ideally, we should probe at the ADC pins to see the interface signal as seen by the device. Incase this is not possible, we will need to test this indirectly.

    1. We first need to confirm that your CFR write access is going thru correctly. You mentioned that during one shot conversion, EOC goes down at the 16th CLK edge and I assume this was seen with CFR=0xA004. Could you try CFR=0xA204 and see the if EOC goes down at the 28th CLK (long sampling)?

    2. If the first step (Write CFR) goes through correctly, we need to understand why we are reading the extra one with the 0x9000 command (Read CFR). Does power up->0xA000->0xA000->0x9000 return 0xX080 as well. I just want to rule out a shift in the data as seen by the processor.

    3. The TLC1518 uses SCLK to derive its conversion clock. 14 conversion clocks are required to complete the conversion. After EOC goes low are we providing sufficient clock cycles to the ADC to complete the conversion and then drive the EOC high again?

    Regards,
    Sandeep
  • 0 in reply to Sandeep Kasargod
    Prodigy 195 points

    Hi Sandeep,

    Sorry about the extra page in the attachment last time...I forgot I had that on another page.  You can ignore the other board in that diagram...it is not being used for this testing.

    After reading your response, and looking at the data sheet in another light, it looks like it takes 12 SCLKs to perform the sampling and then another 2 to finish the conversion.  I was only issuing a 16 bit command, and therefore coming up 2 clocks short.  So, I added a 'dummy' SPI command after the conversion command.  The dummy command simply writes a 0 out on the bus to no one (no CS selected), providing another 16 clocks after my conversion command.  The EOC line goes low sometime during that time, and the values I read now are not zero.  I went ahead and put the conversion command in a for loop and read all 8 channels and compared the results to what I got in the sweep command, and they are comparable....but not right.  Here is a breakdown of the values (Note:  Reference values are 0 & 5V):

    CH   INPUT     A/D value                binary format                       hex                       decimal

    0 = +0.3V        [0x0AB0]              = 00 0010 1010                   = 0x02A               = 42

    1 = +4.8V        [0x4E00]               = 01 0011 1000                   = 0x138              = 312

    2 = -0.4V         [0x0000]               = 00 0000 0000                   = 0x000               = 0

    3 = +0.75V      [0x14A0]              = 00 0101 0011                   = 0x053                = 83

    4 = +0.825V    [0x1BA0]              = 00 0110 1110                   = 0x06E               = 110

    5 = +3.75V      [0xAC10]              = 10 1011 0000                   = 0x2B0               = 688

    6 = +1.05        [0x2B40]              = 00 1010 1101                   = 0x0AD               = 173

    7 = -0.2V         [0x0000]               = 00 0000 0000                   = 0x000               = 0

     

    I also attempted the CFR=0xA000->0xA000->0x9000 and I get 0xX080 in return.  And looking at the above results, obviously the device is not in diff mode or all of my results would have been zero since the diff input (A1) is the negative input and is the highest voltage of all of the inputs.

    Any ideas?  Thanks,

    Joe B.

  • 0 in reply to Joe7216
    Prodigy 195 points
    There's a typo in my response (not sure how to edit)....the EOC line goes back HIGH during the dummy write cycle, so it should.
  • 0 in reply to Joe7216
    TI__Expert 4405 points
    Joe,

    Just to clarify - the device needs min 600ns for sampling and 14 CLKs for conversion, so with a 10MHz CLK and a 16 CLK SPI frame we would have been around 4 CLKs short. However, with the duumy SPI write command we should be comfortable.

    Please note that in your example, CH2 shows an input of -0.4V. This exceeds the Absolute Max Spec of the device and this should be avoided.

    I tried to see if some transfer function can be plotted between input voltage and output code. CH1 is clearly an outlier, but even for the rest of the points there does not seem be a very clear trend. Could you repeat this experiment, ensuring that none of the channels inputs go below 0V?

    Looking at your data, it does seem like your SPI frames are correctly aligned in terms of correspondence between channel number and data as the negative input voltages are returning 0x000 and the positive inputs returns an approximate but incorrect value. I have assumed that you have written CFR=0xA000 before capturing data, to move from the internal 4V reference to the external 5V reference. I tried a few combinations of shifting/scaling the data but could not match the values you are seeing by pure digital manipulation. Also we still do not have an explanation for CFR=0xA000->0xA000->0x9000 returning 0xX080, but this “stuck” bit seems to appear only in the CFR Reg Read and not the data read.

    We will need to review both the your schematics for the ADC section (with the input driver circuit) and oscilloscope screenshots of the SPI interface signals to debug this deeper.

    Thanks.

    Regards,
    Sandeep