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.

TM4C123GH6PM: SPI Communication

Part Number: TM4C123GH6PM


Hello,

I'm currently working on establishing communication with an external ADC - the LTC1298. According to its datasheet, it uses SPI communication to initiate conversions and transfer its readings. Communication with the LTC1298 is half-duplex. As it is my first time working with the SSI modules in TivaWare, and SSI in general, I have a couple questions:

  • According to the LTC1298 datasheet:

    "The CLK synchronizes the data transfer with each bit being
    transmitted on the falling CLK edge and captured on the
    rising CLK edge in both transmitting and receiving systems."

    From my understanding (and according to section 15.3.4.6 of the microcontroller datasheet), this corresponds to the following frame format: SSI_FRF_MOTO_MODE_3 (Polarity = 1, Phase = 1)?
  • The sampling rate of the ADC is 11.1 ksps, and the maximum SPI clock rate it 200kHz. What clock rate would you recommend in this case? Would 150kHz sufficiently account for the sampling frequency?
  • "The data transfer is initiated by a falling chip select signal" - I understand that this part is handled by the TivaWare library upon calling SSIDataPut()? And that chip select returns to its original state after the message is sent?
  • According to the datasheet, the LTC1298 requires the following input data to start the conversion: 

"After CS falls the LTC1298 looks for a start bit. After the
start bit is received, the 3-bit input word is shifted into the
DIN input which configures the LTC1298 and starts the
conversion. After one null bit, the result of the conversion
is output on the DOUT line."

               

  • The conversion is output after one null bit, does that mean I should wait for at least 1 clock cycle before attempting to read the data in the receive FIFO, or does SSIBusy() handle this? Perhaps I should use SSI interrupts instead?

  • I understand that I need to send this message manually to initiate the transaction, using SSIDataPut(). Will my message be sent MSB first, or do I need to reverse it? The last field in the message (MSBF) determines how the data is returned to the Master (MSB first or LSB first) - which option should I choose in this case - i'm assuming MSBF.

  • Finally, the resolution of the ADC is 12-bits. I therefore set the data width parameter in SSIConfigSetExpClk() to 12. Will this work ok for both sending the initial 4-bit message, and then receiving the data?

Taking all this into account, would the following code work (I don't have a way to test it at the moment, and I need to continue with the remainder of the application):

//SPI configuration for LTC1298
SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI1);
GPIOPinConfigure(GPIO_PD0_SSI1CLK);
GPIOPinConfigure(GPIO_PD1_SSI1FSS);
GPIOPinConfigure(GPIO_PD2_SSI1RX);
GPIOPinConfigure(GPIO_PD3_SSI1TX);
GPIOPinTypeSSI(GPIO_PORTD_BASE, GPIO_PIN_0 | GPIO_PIN_1 | GPIO_PIN_2 | GPIO_PIN_3);
SSIConfigSetExpClk(SSI1_BASE, SysCtlClockGet(), SSI_FRF_MOTO_MODE_3, SSI_MODE_MASTER, 150000, 12);
SSIEnable(SSI1_BASE);

while(1)
{
    SSIDataPut(SSI1_BASE, 0x0000000D);
    while(SSIBusy(SSI1_BASE))
    {}

    SSIDataGet(SSI1_BASE, &pui32Data); //pui32Data defined somewhere else
}

Thank you in advance for your help.

Regards,

Ksawery

  • Greetings,

    Staff & I here (outside firm) applaud the 'Care, Depth & Completeness' of your writing!    Far 'above/beyond' that of most poster's - evidenced by (their) rushed & fact-light (i.e. 'Does not Work!')    And 'extra-points' awarded for your 'Use of Bullet Points!'    (Who else - ever - deploys those?)

    To your issue - (try not to 'hate' us):

    • You wrote, "Communication with the LTC1298 is half-duplex" - yet - does not SPI (but) for one 'special mode' - almost always employ 'Full-Duplex?'   (i.e. Data is 'Written & Read' upon EACH SPI Clock Edge - usually different edges for each.)    From where did you determine 'Half-Duplex' as the operating mode?
    • As 'follow' to the above point - your first 'bullet' suggests that 'Full-Duplex' is employed!    "each bit being transmitted on the falling CLK edge and captured on the rising CLK edge" 
    • 'KISS' - you note this as your first ever exposure to SPI - yet the device you've chosen appears (overly) complex - & is likely to frustrate & over-challenge.    We suggest a far simpler, 'SPI Slave Device' - ideally an inexpensive, small capacity, SPI-based EEProm.   (small capacity simplifies device addressing - meeting KISS directives - & you will surely find later use for that chip)
    • Your MCU (which my firm uses - btw) provides 11 ADC Channels - IIRC.    Stand-Alone ADC's (usually) provide superior performance - yet yours, "Sampling rate of the ADC is 11.1 ksps" - flirts w/being, '100X Slower' than the MCU's ADC - while ADDING 'Cost & Space' - rendering your choice 'curious.'

    Beyond these 'initial analysis' points - the following may prove, 'the Killer!'

    You (or the ADC manual) noted,  "After CS falls the LTC1298 looks for a start bit.   After the start bit is received, the 3-bit input word is shifted into the DIN input which configures the LTC1298 and starts the conversion.    After one null bit, the result of the conversion is output on the DOUT line."

    While your inclusion of this writing was 'vital' - what's really needed is a, 'Timing Chart.'

    And the 'plot further thickens' - you've chosen 12 bit SPI data width - yet the (above) requirement demands: 

    • Start Bit (undefined here, btw)
    • 3 Bit Input Word
    • Null Bit
    • 12 bits of Data

    My quick/dirty (back of the envelope) calculation reveals that list to 'well exceed' your 12 bit width - does it not?    (it is assumed that the 'Null' bit's presence demands that the data be included w/in this 'LONG' SPI Sequence.)    Staff & I - at this point - have NO 'Good Answer' for this (seeming) demand...

    Might you 'understand - even accept'  Staff/my hesitation to, 'Dig Deeper?'    Device is highly complex and (appears) w/out an, 'Adequate  Use-Case  having been Built'  -  for its selection & use...

    'Device Selection' is a top requirement for 'Success in this Field' - is this not a 'good time' to 'practice that?'

    TAG Some attention should be devoted to 'KISS!'    (Overly complex - combined w/'first use' - (somehow) seems inefficient...)

  • Hello Ksawery,

    The datasheet for the LTC1298 isn't as descript as I'd like for SPI, but the way the CLK signal is shown being low when CS drops low indicates that it is more likely SSI_FRF_MOTO_MODE_0.

    150kHz should be fine too. I can't imagine there would be much, if any, dependency on the ADC conversion and SPI clock above 100kHz. Note that if using at high temp the D/S recommends staying about 120kHz.

    Ksawery said:
    "The data transfer is initiated by a falling chip select signal" - I understand that this part is handled by the TivaWare library upon calling SSIDataPut()? And that chip select returns to its original state after the message is sent?

    It can be, or you can not configure the SS pin as part of the SSI configuration and instead manually manipulate is a standalone GPIO instead. If the timings for SS from the SSI functions in TivaWare are not working well, I'd recommend that approach.

    You may need to use a dummy write to trigger the ADC and then read afterwards.

    The SSIDataPut API will send out MSB first.

    Ksawery said:
    Finally, the resolution of the ADC is 12-bits. I therefore set the data width parameter in SSIConfigSetExpClk() to 12. Will this work ok for both sending the initial 4-bit message, and then receiving the data?

    If it is allowed you can just pad the 4-bit message with 0's. That's what I would try first so you don't need to adjust that configuration at all.

  • Greetings all,

    As noted from the 2 answering postings - there is substantial difference in recommendation.

    It should be (first) noted that the 'Device Chosen' is spec'ed as 5V-9V powered - thus 'Not really Proper' for use w/3V3 powered MCUs!    There exists another (near identical device) 'LTC1288' - which is (properly 3V3 powered!)    Following are 'key extracts from the LTC1298's data sheet.'    (this illustrates the poster's (admitted) inexperience w/such SPI devices - and why I advised against its use - at this time.)

    Thru good fortune alone 'VIH' proves acceptable.    (usually a 5V powered device seeks beyond 3V5 as its VIH.)    However - 'VOH' exceeds the input capacity of the MCU!    That can be cured - yet the ADC Vendor recommends the (more proper) 'LTC1288' - a 3V3 powered ADC - instead!     That recommendation deserves compliance - and (greater) Attention to Detail...

    Further 'proof & support' of the above is offered w/in the Notes portion of a quickly following spec:    (Yet somehow - 2 here 'missed' this!)

    And - We are about to enter a 'RED FLAG ZONE!'     (Frame's '12 Bit Length' is challenged (Kicked properly to the curb - ideally) as well!)

    As my initial post here well noted - poster's election of a, '12 bit SPI Frame' - cannot accommodate the 'required number of bits!'   (shown in highlight) above.

    And again - NO 'Use Case' was presented for the use of this external ADC - which demands: Added Cost, Space & Complexity!    (And a switch to a different  device - as well...)

  • Hello cb1,

    Regarding the VOH spec on the ADC, for TM4C123GH6PM which has been highlighted here can handle the 5V VOH except for PD4, PD5, PB0 and PB1, which are limited to 3.6 V. Section 24.13.1 GPIO Module Characteristics outlines this in more detail, and the one caveat would be exposing the device to a prolonged period of 5V when VDD is not applied, but I don't believe this ADC would subject the device to such a behavior when powered down.

    That said, it's very fair to question the usefulness of this external ADC vs the built in device ADC.

    Regarding 12 bits vs more - the timing is really strange on this device as it looks like its 4 bits TX and then 12 RX. But I think looking at the timing it wouldn't work to keep the device in 12 bit width. It might make more sense to program for 4 bit length and then use advanced mode to send the 12 clocks on receive sequentially... though this gets fairly complicated and involved for little benefit given its unclear how it would be better than using the onboard ADC.

  • Hello Ralph,

    Good to see that we are, 'Nearing Agreement.'

    Ralph Jacobi said:
    TM4C123GH6PM which has been highlighted here can handle the 5V VOH except for PD4, PD5, PB0 and PB1

    While that's true - the ADC Vendor clearly recommended (In Writing!) the use of a 'Far more suitable' 3V3 powered, equivalent device!    That clearly would have been a Superior Choice!

    Ralph Jacobi said:
    Regarding 12 bits vs more - the timing is really strange on this device

    Indeed - as my 'first responding post' well noted.     Very 'bad choice' for a 1st time SPI poster!

    Ralph Jacobi said:
    I think looking at the timing it wouldn't work to keep the device in 12 bit width

    No 'think that' - a 'For Sure' wouldn't work w/ 12 bit width!    Of course - 'Switching Frame bits is 'Not for a 1st time SPI poster.'

    Ralph Jacobi said:
    this gets fairly complicated and involved for little benefit given its unclear how it would be better than using the onboard ADC.

    And again - that was EXACTLY the thrust of my 'first responding post!'     Recall as well - 11.1kps is FAR SLOWER than the ADC w/in 'your' MCU!

    Just maybe - sometimes - 'Encouraging poster desire - when it, (pardon) may make little sense and in fact 'Adds Great Complexity' - may prove mistaken...

  • Hi cb1,

    ...I may have committed the cardinal sin of not reading through your initial post yesterday before crafting my own reply. Skimming did me no favors, clearly.

    I 100% agree that the 3.3V device is a better choice but "However - 'VOH' exceeds the input capacity of the MCU!" was not factually correct for this device except for the aforementioned 4 pins, so I just wanted to clarify that for other readers which is why I mentioned all of that. The conditions to ensure 5V exposure is safe requires a lot of system-level consideration and reading of the manual to understand what is and isn't allowed, so it's absolutely recommended to just avoid that situation as a whole if at all possible.

    Also worth mentioning that the 5V tolerance is one of the large differences between TM4C123x and TM4C129x, as the TM4C129x only has 5V tolerance on the single USB VBUS pin on devices which have it.

  • Ralph Jacobi said:
    may have committed the cardinal sin of not reading through your initial post

    Indeed - that happens - yet 'Vendor Staff' service many - cb1 & crüe are free to, 'Pick & Choose.'    And to, 'Save Posters from themselves!'    (i.e. 'Hoist by their own Petard!')    Posters do not ALWAYS make the best decisions - nor come to correct conclusions - nor have the ability to regularly, 'Match my group's, 'Understanding, Experience & Work Ethic!'

    I must 'defend' the 'VOH exceeds' statement - even though - especially though - only 4 pins are impacted!     At minimum - this 'warning' should 'Force the User to 'better & or further review' - the MCU Manual.    And we have 'No CLEAR promise' that he would not use one of those 4 pins!    In addition - the '123 LPad' exposes 39 GPIO - 4 are 'absorbed' by his SPI - thus '4/35  that's 11.4%!   That indeed demands a CAUTION - and thus is not, factually incorrect.   It is - more properly - 'Conditionally Biased and/or Impacted!'    (credit UCLA Law for the analysis.)

    Ralph Jacobi said:
    ensure 5V exposure is safe ... absolutely recommended to just avoid that situation as a whole if at all possible.

    And - demanding 'restatement' - my earlier identification of a, 'FAR SAFER (3V3) ADC' - noted as such by the ADC Vendor' - eliminates (any) such 'VOH' issue...

    And STILL - there exists  DAMAGE to the claim of, 'Not factually Correct!' 

    Our poster NEVER stated that he would run the ADC from (only) a 5V Supply!   Note that  the ADC's 'Page 1 Data' reveals, the supply is 'MINIMUM of 5V - ranging to 9V!' 

    As the below well notes - this ADC is (often) employed for Battery Use - a 9V Battery proves a, 'Most Usual Suspect' - and the increased VOH will then (surely) 'KILL YOUR MCU!'    

    My CAUTION in regards to VOH thus (continues) as 'Well & Safely Advised!'     There (may) exist 'factual uncertainty' - but NOT 'incorrectness.'   (We called ADI - and they too were 'uncertain.')


    Being guaranteed 'SAFE' always trumps 'SORRY'  (especially when Safe arrives thru 'luck' only!)  - you surely agree...

  • Thank you very much for taking the time to look into this, as well as your expressed concerns regarding the supply voltage of the ADC. Unfortunately, as I'm primarily a programmer, I don't have experience in the design of the actual circuitry. I assume, however, that my supervisor has taken these factors into account when selecting the LTC1298 device. I'm only tasked with establishing communication with the device on the specified pins. I can, of course, forward your recommendations to my superior.

    I'm also still relatively new to embedded programming and the TM4C123GH6PM controller. So far, I have successfully designed one application, in which the MCU acts as a Modbus slave (communicating with Linux systems) and I2C master - gathering readings from an external ADC (ADS 1110). I've also completed all TM4C123G Launchpad Workshops and regularly make use of the Peripheral Driver Library Manual and the MCU Datasheet. That's as far as my experience goes at the moment.

    Regarding your recommendations:

    cb1_mobile said:
    • You wrote, "Communication with the LTC1298 is half-duplex" - yet - does not SPI (but) for one 'special mode' - almost always employ 'Full-Duplex?'   (i.e. Data is 'Written & Read' upon EACH SPI Clock Edge - usually different edges for each.)    From where did you determine 'Half-Duplex' as the operating mode?
    • As 'follow' to the above point - your first 'bullet' suggests that 'Full-Duplex' is employed!    "each bit being transmitted on the falling CLK edge and captured on the rising CLK edge" 

    The device features specify that the ADC I/O is compatible with "SPI, Microwire, etc.":

    Also, examples of interfacing with various MCUs using SPI, microwire or serial interfaces are provided at the end of the datasheet:

    Hence my assumption that establishing SPI communication between the TM4C123GH6PM and LTC1298 should be relatively straightforward - given the right configuration and parameters. However, after looking through the examples, I wasn't exactly sure as to which method I should refer to (each one is different). Regarding your concern of the half-duplex nature of the communication, that's described (briefly) in the datasheet:

    Ralph Jacobi said:

    The datasheet for the LTC1298 isn't as descript as I'd like for SPI, but the way the CLK signal is shown being low when CS drops low indicates that it is more likely SSI_FRF_MOTO_MODE_0.

    Thanks, I'll try using this mode for now.

    Ralph Jacobi said:

    If it is allowed you can just pad the 4-bit message with 0's. That's what I would try first so you don't need to adjust that configuration at all.

    The datasheet specifies that all leading zeros will be ignored, so that should be ok:

    Ralph Jacobi said:

    It can be, or you can not configure the SS pin as part of the SSI configuration and instead manually manipulate is a standalone GPIO instead. If the timings for SS from the SSI functions in TivaWare are not working well, I'd recommend that approach.

    Thanks, I'll try using the TivaWare library for now, and see if the timings are ok by default. If not, I'll try your suggested method.

    Ralph Jacobi said:

    Regarding 12 bits vs more - the timing is really strange on this device as it looks like its 4 bits TX and then 12 RX. But I think looking at the timing it wouldn't work to keep the device in 12 bit width. It might make more sense to program for 4 bit length and then use advanced mode to send the 12 clocks on receive sequentially... though this gets fairly complicated and involved for little benefit given its unclear how it would be better than using the onboard ADC.

    Would you be so kind as to provide a programming example as to how this advanced mode would work?

    Also, how does the frame size parameter impact the SPI communication exactly? Does the SPI clock work in bursts of N bits = frame size, with a delay in-between? Does this delay account for the null bit after the start of the ADC conversion? Or does the chip-select signal return to its positive state after each frame? In that case (as cb1_mobile noted I believe), shouldn't the frame size = 16?

    Hopefully I will be able to test these settings and your recommendations soon, when the circuit is completed.

    Thank you in advance for your help and apologies for the large number of questions :)

    Best regards,

    Ksawery

  • There remains 'No/Zero' justification for the use of, 'So complex a device' - especially when the MCU is equipped w/11 ADC Channels - the 'add-on one proposed' is 2 Channels (only) - and vendor's MCU is  (near) 100x Faster.

    I cede this to vendor staff - and still - the choice of this particular device was (and apparently remains) improper.     There IS a more appropriate 3V3 powered device - which my group - far earlier - well identified & listed!     (to continued Silence!)    Should that 'mistaken selection' continue ... forever?    Not for my team...

    Good luck - more productive 'battles' beckon.  

  • Hello Ksawery,

    This E2E post outsides how to use Advanced SSI mode for such an application: 

    You'd need to adjust the bit length to be 4, as it is 8 for the use case in that post.

    In Advanced Mode you could get all clocks with a low SS the whole time for however many transactions you are making. So if you send 4 bits, then you would get 4 clocks with SS low. If you need to read 12 bits back, you would do 3 reads to get 12 clocks generated in a row with SS low.

  • Thank you for your reply.

    Here is the configuration that I'm now using:

    //SPI configuration for LTC1298
    SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI1);
    GPIOPinConfigure(GPIO_PD0_SSI1CLK);
    GPIOPinConfigure(GPIO_PD1_SSI1FSS);
    GPIOPinConfigure(GPIO_PD2_SSI1RX);
    GPIOPinConfigure(GPIO_PD3_SSI1TX);
    GPIOPinTypeSSI(GPIO_PORTD_BASE, GPIO_PIN_0 | GPIO_PIN_1 | GPIO_PIN_2 | GPIO_PIN_3);
    SSIConfigSetExpClk(SSI1_BASE, SysCtlClockGet(), SSI_FRF_MOTO_MODE_0, SSI_MODE_MASTER, 150000, 4);
    SSIAdvFrameHoldEnable(SSI1_BASE);
    SSIAdvModeSet(SSI1_BASE, SSI_ADV_MODE_WRITE);
    SSIEnable(SSI1_BASE);

    From the timing diagram of the LTC1298, I believe I need a total of 17 clocks to send the instruction and receive the 12 bit ADC reading (4 bits instruction, followed 1 null bit, followed by 12 bits reading). Based on the suggested post, I implemented the following sequence of events:

    if (!SSIBusy(SSI1_BASE))
    {
        //Trigger SPI communication
        SSIDataPut(SSI1_BASE, 0x0D);
        SSIDataPut(SSI1_BASE, 0x00);
        SSIDataPut(SSI1_BASE, 0x00);
        SSIDataPut(SSI1_BASE, 0x00);
        SSIAdvDataPutFrameEnd(SSI1_BASE, 0x00);
    
        //Retreive data from FIFO
        SSIDataGet(SSI1_BASE, &ulSPIReading);
        usRegInputBuf[0] = (USHORT) (ulSPIReading >> 3);
    }

    I'm not sure how the receive FIFO works exactly - will the 12 bits be stored in a single register in this case, or will each 4 bits be stored in a separate one?

    Here is the clock and FSS signal output from my scope - only 4 clocks are generated for FFS low, for some reason.

    Curiously, when I switch to SSI_FRF_MOTO_MODE_3, I get the following outputs:

    Regards,

    Ksawery 

  • Hello Ksawery,

    Ksawery said:
    I'm not sure how the receive FIFO works exactly - will the 12 bits be stored in a single register in this case, or will each 4 bits be stored in a separate one?

    The common receive FIFO is a 16-bit wide, 8-locations deep, first-in, first-out memory buffer. Received data from the serial interface is stored in the buffer until read out by the CPU, which accesses the read FIFO by reading the SSIDR register

    I would anticipate the FIFO will store 4 bits per location - with the other 12 bits probably being set to 0. So you should need to read the FIFO for each 4 bits received and stitch the results into a 12 bit value. 

    Your code doesn't look right for what you are doing.

    After sending the 4 bit value, if you are receiving next, then do not do this:

        SSIDataPut(SSI1_BASE, 0x00);
        SSIDataPut(SSI1_BASE, 0x00);
        SSIDataPut(SSI1_BASE, 0x00);

    Instead, that is when you want to do your SPI reads:

    SSIDataGet(SSI1_BASE, &ulSPIReading);
    SSIDataGet(SSI1_BASE, next_store_location);
    SSIDataGet(SSI1_BASE, next_store_location2);

    You would need to decide where the next two data nibbles are read so I just left dummy names for them. The SSIDataGet will generate the clocks.

    You may not need:

     SSIAdvDataPutFrameEnd(SSI1_BASE, 0x00);

    Until the very end to get the SS line high again - especially if the DS indicates the SS line should not rise between the 4 bit transmission and the 12 bit reception.

  • Hi Ralph.

    Thank you again for your help.

    As per your recommendation, I implemented the following:

    while(1)
    {
        SSIDataPut(SSI1_BASE, 0xD); //send 4-bit instruction
    
        SSIDataGet(SSI1_BASE, &ulSPIReading); //read bits 12-10 (1st bit is null)
        SSIDataGet(SSI1_BASE, &ulSPIReading); //read bits 9-6
        SSIDataGet(SSI1_BASE, &ulSPIReading); //read bits 5-2
        SSIDataGet(SSI1_BASE, &ulSPIReading); //read bit 1
    
        SSIAdvDataPutFrameEnd(SSI1_BASE, 0);
    }

    I plan to put the data in the right place once I get the application working, just using the ulSPIReading variable repeatedly for testing purposes.

    I also updated the advanced SSI configuration to SSI_ADV_MODE_READ_WRITE, instead of SSI_ADV_MODE_WRITE, since i'm both writing to and reading from the slave.

    Unfortunately, the whole application hangs on the 3rd call to SSIDataGet(). The ADC is currently not connected, but I guess that shouldn't stop the SSI functions from working - even if the Rx FIFO is empty?

    Regards,

    Ksawery

  • Ok, after doing some more research, I believe I finally found what I was looking for, in the TM4C123G Datasheet:

    Unlike the full-duplex transmission of the other two frame formats, the MICROWIRE format uses a special master-slave messaging technique which operates at half-duplex. In this mode, when a frame begins, an 8-bit control message is transmitted to the off-chip slave. During this transmit, no incoming data is received by the SSI. After the message has been sent, the off-chip slave decodes it and, after waiting one serial clock after the last bit of the 8-bit control message has been sent, responds with the requested data. The returned data can be 4 to 16 bits in length, making the total frame length anywhere from 13 to 25 bits.

    What the LTC1298 ADC is actually using, is the MICROWIRE SSI format. As described in the LTC1298 datasheet, the communication is half duplex, and the device expects an initial 4-bit instruction message. After decoding the message, and clocking in one null bit, it sends a reply that is 12 bits in length. Data is clocked in on the rising edges of the clock, and FSS is held low during the entire transaction. The clock is held low and FSS is held high in the idle state. This corresponds exactly to the MICROWIRE format, although it wasn't explicitly stated as such in the LTC1298 datasheet (only briefly at the beginning). For a person that is unfamiliar with this format (such as myself), this can be a bit confusing.

    I used the following SSI configuration (with all advanced modes now disabled):

    SSIConfigSetExpClk(SSI1_BASE, SysCtlClockGet(), SSI_FRF_NMW, SSI_MODE_MASTER, 150000, 12);

    And the following code to read/write data:

    while(1)
    {
        ... //remainder of application
    
        SSIDataPut(SSI1_BASE, 0x0B); //send instruction
    
        while (SSIBusy(SSI1_BASE)) {}
    
        SSIDataGet(SSI1_BASE, &ulSPIReading); //read data
        usRegInputBuf[0] = (USHORT) ulSPIReading;
    }

    The CLK and FSS outputs on my scope are now as follows:

    These outputs, I believe, are now correct. There are 21 clock signals during the time that FSS is held low. I'm assuming, that these correspond to the initial 8-bit instruction (the first 4 zeros of the 8-bit instruction will be ignored by the LTC1298), followed by 1 null bit, followed by 12 data bits read from the device = 21 in total.

    The circuit should be completed by tomorrow, so I should be able to test the application then, but for now i'm optimistic with the result.

    EDIT: the initial instruction (0x0B) is sent at the expected time - 4 zeros followed by the 4-bit input word (top trace = SSI Tx channel):

    Best regards,

    Ksawery

  • Hello Ksawery,

    Thanks for reporting your findings here. I hadn't run into a use case for that mode before so I really wasn't knowledgeable about it. The protocol doesn't sound so strange now! Good luck with the hardware when it arrives.

    I would still recommend seeing if you can use the TM4C ADC as well. You may be able to save system cost that way.

  • You are to be applauded for persistence.     While the method shown 'appears to succeed' - might weaknesses (still) lurk?    And - might an (even) more efficient method exist?    

    Our Tech Group employs (only) the TM4C123 series from this vendor - thus your chosen, 'SSI_FRF_NMW' is unavailable to the many, '123 users!     The more normal & available, 'Microwire Frame Format' (SSI_FRF_TI IS available however - and appears (also) to succeed!

    With that noted - it  appears likely that an (even more inventive) method - employing  'Just 16 clocks' (down from poster's 21) - has a strong 'likelihood of success' - and  FAR Better (i.e. Alone) 'Recognizes & Exploits'  ADC Performance Reality!

    As my far earlier post noted - the device's timing chart reveals that '17 clocks' are required to perform a complete & proper, 'Device Command & Data Reception.'    How then - can 'Just 16 clocks' work?    This is where 'Design Experience' - which, 'Exposes Circuit Implementation (i.e. Real World) REALITY' - enters the picture!    It is (almost) certain that the 17th clock - which captures the 'Least Significant Bit' of the ADC's Data Stream - will present that last bit, 'JITTER-RICH!'   Thus  w/out any REAL Value!     (And likely 'flawed too' - the adjacent bit!')    And thus we (quite properly)  'Cast (Noise Plagued) 'bit 17' to the curb!'

    [EDIT]:  11:22 CST  - there exists a (possible) 'Jitter Mitigation' method - which (may) explain - the Turtle-Like Conversion Speed of this ADC.   (11.1Ksps (downhill) - readings may be being 'Averaged' prior to being presented.    (Such cannot SAVE those first several readings - thus I doubt this (possible) 'saving attempt' - (was/is) deployed...)

    Then - following Vendor Ralph's (earlier) suggestion of 'Freescale's 'SSI-FRF_MOTO_MODE_0' - but (now) set to '16 bit data width' - success IS enabled!    And - it should be noted - that 'this Freescale mode' is usually, 'FAR More Popular, Useful & Productive' - than the one chosen, above...

    The 'new/improved' SSIDataPut() will (more efficiently) send, "0xFXXX" (i.e. 16 bits - MINUS ALL FOUR of those initial, 'WASTED '0' BITS!')   (lower order nibbles w/in  the 16 bit length - all, 'Don't Care!')

    Alas - (also) as repeatedly noted, 'Trouble most likely awaits those' employing the 'LTC1298' and driving it from a '3V3 only' capable data source  ...  even though - and especially though - both the ADC Vendor & this reporter - have (earlier & repeatedly) 'Sounded the Alarm!'     (And to add 'pain/suffering' - this 'bit obscure (sig. level) issue' often, 'Evidences as Intermittent!)

    It is good to see the vendor join my (first & earlier) repeated questioning of, "Why 'this' 2 Ch. (or 1 DIFF Ch.) ADC?" - when the MCU is (both) 'ADC Loaded - and (effectively) 100x Faster!'