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.

CCS/TM4C123GH6PM: SSI Help with AD4001 ADC

Part Number: TM4C123GH6PM


Tool/software: Code Composer Studio

I am tasked with reading an AD4001 ADC (Analog Devices) at 4kHz.  I appear to be reading data from the ADC but it is not reliable.  Does anyone have experience with this device?

I have the TM4C123G Launchpad connected to the ADC:

SSIOTX is NC

SSIORX is connected to the SDO pin

SSIOCLK is connected to the SCK clock pin.

I am using a GPIO to control the CNV pin.

SDI on the ADC is pulled high to VIO.

I'm looking at the SPI on the scope and it looks like on some occasions, there is data on the line before the clock starts? 

Here is the code snippets: 

(INITIALIZATION)

void SpiInit_SSI0(void) {

// The SSI0 peripheral must be enabled for use.

SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI0);

// For the TM4C123G, SSI0 is used with PortA[5:2].

SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);

// Configure the pin muxing for SSI0 functions on port A2, A3, A4, and A5.

GPIOPinConfigure(GPIO_PA2_SSI0CLK); // Configure PA2 for the clock

// GPIOPinConfigure(GPIO_PA3_SSI0FSS); // Use a GPIO for the *CS function.

GPIOPinConfigure(GPIO_PA4_SSI0RX); // Configure PA4 for the Master Receive

GPIOPinConfigure(GPIO_PA5_SSI0TX); // Configure PA5 for the Master Transmit

GPIOPinTypeGPIOOutput(GPIO_PORTA_BASE, GPIO_PIN_3); // Configure PA3 as a GPIO for *CS

// Configure the GPIO settings for the SSI pins. This function also gives

// control of these pins to the SSI hardware. Consult the data sheet to

// see which functions are allocated per pin.

// The pins are assigned as follows:

// PA5 - SSI0Tx

// PA4 - SSI0Rx

// PA3 - SSI0Fss - Not Used

// PA2 - SSI0CLK

GPIOPinTypeSSI(GPIO_PORTA_BASE, GPIO_PIN_5 | GPIO_PIN_4 | GPIO_PIN_2);

GPIOPinWrite(GPIO_PORTA_BASE, GPIO_PIN_3, 0); // Enable the GPIO pin for *CS

// Configure and enable the SSI port for SPI master mode. Use SSI0,

// system clock supply, idle clock level low and active low clock in

// freescale SPI mode, master mode, 1MHz SSI frequency, and 8-bit data.

// For SPI mode, you can set the polarity of the SSI clock when the SSI

// unit is idle. You can also configure what clock edge you want to

// capture data on. Please reference the datasheet for more information on

// the different SPI modes.

SSIConfigSetExpClk(SSI0_BASE, 80000000, SSI_FRF_MOTO_MODE_0,

SSI_MODE_MASTER, 20000000, 16);

// Enable the SSI0 module.

SSIEnable(SSI0_BASE);

uint32_t pui32DataRx[2];

// Read any present data from the SSI port. This makes sure the receive

// FIFOs are empty, so we don't read any unwanted junk. This is done here

// because the SPI SSI mode is full-duplex, which allows you to send and

// receive at the same time. The SSIDataGetNonBlocking function returns

// "true" when data was returned, and "false" when no data was returned.

// The "non-blocking" function checks if there is any data in the receive

// FIFO and does not "hang" if there isn't.

while(SSIDataGetNonBlocking(SSI0_BASE, &pui32DataRx[0])){ }

}

GPIO_PORTA_DATA_R |= 0xFF;

SysCtlDelay(4);

GPIO_PORTA_DATA_R &= 0xF7;

SSIDataPut(argSsiBase, 0x1400); //0x1406); //pui32DataTx[ui32Index]);

// Wait until SSI0 is done transferring all the data in the transmit FIFO.

// while(SSIBusy(argSsiBase)){}

uint32_t data = 0xCCCCCCCC;

SSIDataGet(argSsiBase, &data);

// while(SSIBusy(argSsiBase)){}

return convertToVoltage((int16_t)(data & 0xFFFF));

  • Hi Brian,
    So, are you using 3-wire without busy indicator on the AD4001? I don't think you should call "SSIDataPut". I think you are losing the results and it is not writing to the AD4001 (SSI0TX is not connected). Comment out that line.

    One suggestion to make your posts more readable, select "Use rich formatting" and then paste your code using the "</>" button. It then preserves your indent levels and does C color formatting.
  • I thought the same thing and I tried that. I never see the transfer on the scope. It just hangs in the SSIDataGet call.
  • Is there a way to initiate the transfer without writing to the SSI interface first?
  • Sorry, I thought as a Master it would initiate the transfer, but you are right. The SSIDataPut() does the transfer, and SSIDataGet() then just returns the value in the receive FIFO. (There goes my image as an expert :( )

    How much is the data off? Is it off in just the lower bits, or is it totally random?
  • totally random unfortunately. I have the inputs shorted together, expecting 0 result and I'm seeing anywhere from -1.2 to +3.9
  • Hi Brian,
    I received an e-mail from customer support with the following information I assume you provided them:

    Problem: Tasked with implementing an Analog Devices AD4001 high-speed SPI ADC into an existing product. Prototyping the system with a TM4C123G Launchpad. After extensive contact with Analog Devices, the conclusion is that the timing/frame of the SPI interface is not correct.
    I have a GPIO connected to the conversion pin of the ADC.
    SSI0Rx connected to the SDO line on the ADC
    SSI0CLK connected to the SCL line on the ADC.
    SDI on the ADC is tied to Vcc. (three wire mode)
    I am using the Tivaware SSI library.
    There are communications between the ADC and the TIVA, but the viewing the timing on a scope indicates that that is too much delay between the CVN pin going low and the clock starting on the SPI interface. We are not writing anything to the ADC, but the only way I can get a transaction to initiate is by doing an write prior to the read.]

    Can you share the scope picture? What is the maximum time from convert going low to the first SSI0CLK edge allowed by the Analog Devices specification?
  • DataValid.pdf

    I just captured this image.  It looks like the Tiva is reading exactly what the ADC is putting on the line.

  • Looking at the Analog Devices spec I don't see any maximum time specification from convert low to start of SPICLK.

    That is, if I found the right datasheet:

    http://www.analog.com/media/en/technical-documentation/data-sheets/AD4001.pdf

  • Bob Crosby said:
    I received an e-mail from customer support with the following information I assume you provided them:

    Bob - even a simple outsider must "memorialize" the great effort you've made in support of this poster.   Simply terrific.

    You have fully & efficiently covered ALL pertinent aspects of the TM4C's behavior - the great bulk of  this issue involves "ANOTHER Vendor's" device - such should NOT become "your" responsibility!

    Being past involved in a similar role - in which we were called upon to, "Support everything" - I "KNEW" that, "SO WIDE an OPENING of the Forum's GATE" would invite such issues.   Beyond this poster - who really benefits from this (specific) struggle?   There are (many) others here seeking REAL TM4C guidance - do not they suffer when "Key Vendor Support Agents" are "Forced away from their area of focused expertise" - especially when this involves Non-Vendor/Non MCU devices?

    Is this forum destined to support "EVERY DEVICE" from ALL Vendors - long into the future?    That's a (very) slippery slope - with predictable (NEGATIVE) results - and (pardon) appears NOT well considered!

    The fact that "customer support" finds it necessary to contact you - even, "after all you've done for this poster" - rings as "unfair & misguided!"   If useful - I'd be glad to contact them and advise of the depth & responsiveness of your effort - which is especially notable as the issue at hand (primarily) involves ANOTHER vendor's device!   It would seen that "customer support" has INVITED this issue - and now turns a "blind/denying eye" to their (unfortunate) creation...

  • Believe that key facts (remain) absent from this thread.   Listed are those which (may) lead to success w/this NON-VENDOR device!

    • This ADC is complex - requires a "top-flite" pcb design - unstated is the board design poster has implemented!   Vendor's Eval board is ideal - especially during development.
    • Earlier the data recovered was noted as, "unreliable."    (which provides little diagnostic value)   Today arrives a SINGLE SCOPE CAPTURE - and no report of this data's "reliability!"
    • What do repeated accesses of this ADC reveal?
    • Earlier it was noted that the ADC inputs were "shorted."   I'm uncertain if that is proper for such a device - which seeks a true "differential" signal input.   Would not an "in range" proper, known, differential signal input prove far superior?
    • Do additional such "ADC boards" exist - and have they been tested?
    • Is power & power distribution appropriate for such a 16 bit ADC?   Have any/all "noise sources" been removed during this test/verify?

    During your initial post you noted, "Data output by the ADC (in advance) of your SPI clock!"   Thanks to vendor Bob's presentation of the AD spec - I saw that today too - yet the vendor notes that the MSbit of the SPI data-train "presents/appears" w/the "fall of CNV" - AND THEN PERSISTS - until the first SPI clock arrives.   Only then - does "normal/customary SPI clocking advance data!"   (strange to say the least...)  You noted this, "premature arrival of SPI data" as "occasional" - by my read - it is "ALWAYS!"   (and likely signals some error if  "occasional" proves true...)

    There are likely more "items of interest" - yet much effort has been expended - and these facts (which may help resolve) have yet to be presented...

  • I'm a little offended by the last post.  In the real world with tight schedules and limited resources, when something doesn't work it is not uncommon to take a multi-path approach to mitigate risk. Analog Devices provided a dedicated Applications Engineer to our request for support.  That engineer provided me his email and a direct phone number (as well as a cell phone number while he was travelling.)  I sent an email to customer support hoping to get a similar response from TI.  However, it appears that this "support forum" is really just a place for experienced users to bash those of us trying to learn. 

    Bob, I appreciate your response.  I was pretty sure that the TIVA was reading what the ADC was putting on the wire.  Lockheed management wanted me to get an applications engineer "on the hook" on the TI side as well, hence the email to customer support.

  • None of "today's facts" were past presented - indeed AD's support team should have been deeply engaged - my writing (may) have been lightened w/those facts in evidence.    You wrote of  "bashing" - yet as I've attended (both) engineering & law school - may I ask "Where/how" you've been bashed?   (we were trained to "avoid" such charge - yet make our point)    Might you have "mis-read" my care/concern for this forum?    

    You fail to make any mention of the (detailed) tech guidance I've provided (06 April, 23:06) - which enabled another firm to past succeed w/"Just that device!"   (might that lessen your sense of "offense?")   As (among - if not the longest-term forum user here) I feel some duty to "protect the forum" - and as an outsider - my (lesser, yet still proper) "PC constraints" enable the identification of potentially destructive forum movements.

    This forum could not succeed (nor likely continue) if the bulk of such "Tech. requests" targeted "Non-Vendor" devices.  You avoid acknowledgement of that fact (for obvious reasons) - do you not?

    We've not had the pleasure of your response to the (pertinent) Tech. questions earlier raised (06 April, 23:06) in your behalf - all designed to "meet your tight schedule" by employing an "outsider" to augment "limited resources."  Your sense of "offense" may be improper (and stands unidentified.)

    Client of ours happened to use that exact ADC roughly 18 months past.  MCU was (another's) Cortex M4 - I've messaged them for further guidance. (they employed several such devices in, "daisy chain" - and my firm assisted in their success.)

    Here's a direct quote from the AD datasheet which Bob provided:
    "It is important to note that the differential input signals must be truly antiphase in nature, 180° out of phase, which is required to keep the common-mode voltage of the input signal within the specified range around VREF/2 shown in Table 1."

    I believe that your providing the ADC w/such (specified) input signal to be in your best interest.  (surpassing the "easier" method you (earlier) listed)  It should be noted that Lockheed (among similar others) has been a (satisfied) client of my firm...

  • Hi Brian,
    No problem. I understand your position. I always try not to quickly point to the "other" chip as the problem. I fully understand the frustration of being caught between two vendors each pointing to the other. In this case, however, I don't see any issues with the behavior of the TM4C. I also understand how management tries to "help" by forcing escalation. I've been around long enough that that does not offend me.

    Now to the real point. How do we get this to work? I have sent you a friend request so that you can contact me directly. We can setup a three-way phone conference with Analog Devices if you think that might help.

    Another thought, you might consider CB1's suggestion and try to bias the differential pins to GND, VREF or somewhere in-between. It may not be happy with the two pins tied together and floating. But in that, I would defer to the Analog Devices engineer.
  • Bob - thank you for that, "vote of confidence."   Such "quick/dirty" implementations (shorting/floating the inputs) - especially when applied to so demanding a device - incur high elements of risk.

    We (still) know "nothing" of poster's ADC board!   An improper layout, component choice/locating or routing cannot succeed w/so complex a device.

    The questions raised earlier (post 06 April, 23:06) "aim to assist" - and (remain) unanswered...   (when a proper board design is provided - we KNOW that device to work!)

  • The ADC input pins are tied together and left floating at the recommendation of the AD applications engineer. I had them both tied to ground and he recommended not going that, but instead shorting them together.

    My contact with you was not to sort out the ADC itself, but to determine the validity of my SSI implementation. In the meantime, I have received other components with SPI interfaces and all are operating reliably. I know the ADC WILL work, I've used them on other programs. However, the other programs used SOC and the ADCs were interfaced from the FPGA at very high speed and the data placed in a ring buffer, so the ARM could grab it when needed. I've never implemented a high speed SPI ADC from the Tiva and that is what I wanted help/validation with. The analog guys are working the actual conversion side.
    By the way, I'm not at the point of sampling at 4kHz with invalid data about every 15-20 samples. So, I'm confident the SSI interface is good. Thanks again for your help.
  • If you are achieving 14/15 and/or 19/20 "valid samples" you appear "well on your way!" Good that.
    Might you confirm that yours is (either) an AD Eval board or a "pro-designed" board (possibly one of your past ones) by your skilled team?    Board implementation IS key/critical...

    I remain (uncertain) about the treatment of your ADC's input.  We hope that the "valid" samples you are achieving result from a "proper" differential signal input - just as the AD datasheet directs...

  • Working with the AD support, the timing between the falling edge of the conversion signal and the start of the SPI read was off by about 10ns. I am now sampling 100% accuracy at 8k (2x oversample from my requirement).
    The board was designed and built my myself in house.
  • Brian Savage said:
    ...the timing between the falling edge of the conversion signal and the start of the SPI read was off by about 10ns.

    Both Bob & I searched (separately) for that spec - neither of us could find it.

    My read of the data noted that the MSbit was (immediately presented) upon the "Fall of CNV" - without (any) regard to the "first/initial" SPI clock.   (and your scope capture revealed just that!)

    If convenient - might you note where that particular timing spec appears?   (we assume that by "SPI read" you mean the "arrival of first SPI clock.")   (i.e. time delta between CNV fall & SPI clock's arrival)   Is this correct?

    Perhaps to your benefit - we advised our client to "design/build" for future expansion - and shortly they added another AD4001 - thanking us for that, "heads up."

    Congratulations on your board design - we've implemented such boards (up to 20 bits) and (rarely) did the "first round" boards perform to expectations.   (sweating the details - (very) much required)

  • the spec came from AD support. min of 320ns on the CNV line, then min of 10ns before the first rising edge of the SPI clock.

    This design needs the speed of the ADC more than the accuracy (I really only need 14 of the 16 bits.) The next step is a PCB (I'm on a soldered board right now that was painstakingly constructed). With everything working on the soldered board, the expectation is that it will get better (accuracy) on the PCB.
  • Btw, this is round #3. I have piles of scrap boards in my workbench drawer.
  • Brian Savage said:
    the spec came from AD support. min of 320ns on the CNV line, then min of 10ns before the first rising edge of the SPI clock.

    Thank you - appreciated.   This explains why (neither) Bob, I (and all others) could NOT find that data!

    I risk rising (even) further on your "S-list" - yet we should note that as your MCU provides the CNV signal - is it not (extremely) unlikely that your "MCU could (then) drive the SPI clock QUICKER than w/in 10nS - after dropping CNV?"   (if irc - this vendor's MCUs drive the SPI clock (and data) upon a "PUT" command - which must follow the "GPIO's CNV fall.")   I cannot imagine that occurring w/in that 10nS "window!"   Not close!

    So - your issue must have resulted (instead) from a violation of the 320nS CNV (min).    (uncertain how/where that's specified or measured.)

    I (am) trying to be of some value here - and these timing items - as I've identified & presented - do raise concern...