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: ADS1292R Interface with TM4C1294NCPDT TIVA C micro controller

Part Number: TM4C1294NCPDT
Other Parts Discussed in Thread: ADS1292R

HI,

I am trying to interfece ADS1292R ECG AFE with TM4C1294NCPDT TIVA C micro controller.

I have configured SSI0 as below.

void SPI_Setup()
{
SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI0);

SSIDisable(SSI0_BASE);

GPIOPinConfigure(GPIO_CONFIG_SSI0CLK);
GPIOPinConfigure(GPIO_CONFIG_SSI0RX);
GPIOPinConfigure(GPIO_CONFIG_SSI0TX);
GPIOPinConfigure(GPIO_PA3_SSI0FSS);

GPIOPinTypeSSI(GPIO_PORTA_BASE, (GPIO_PIN_2 | GPIO_PIN_4 | GPIO_PIN_5 | GPIO_PIN_3 )); // SPI0
SSIAdvModeSet(SSI0_BASE,SSI_ADV_MODE_LEGACY);
SSIConfigSetExpClk(SSI0_BASE,                                                                                                              // SPI0
40000000,                                                                                                                                                    // System Clock for SSI clock
SSI_FRF_MOTO_MODE_1,                                                                                                                       // Data frame format (polarity 0, phase 1)
SSI_MODE_MASTER,                                                                                                                                // Configure as Master
SSI0_SPEED,                                                                                                                                             // Set speed
8);                                                                                                                                                               // Byte-long word length

SSIEnable(SSI0_BASE);

}

My Connections are shown in the attached file 

     TIVA C Controller---- ADS1292R

PN4 ------ARD_PWDN/RESET

PQ0------ARD_START

PQ1------ARD_DRDY

PA3-------ARD_CS

PA4-------ARD_MOSI

PA5-------ARD_MISO

PA2------ARD_SCK

I am trying to write the registers of ADS1292R through TIVA C controller. I could see the data and clock on oscilloscope as expected but I am unable to confirm if the ADS has received data properly.

I have followed the data sheet of ADS to write single register in following way

First byte----Write Opcode | Register address

Second Byte--- (no of registers to write-1)

Third Byte----- Register Data

Now I tried back to read the written register, what I expect is to read the value back which I have written already, Read is done through following way.

First byte----read Opcode | Register address

Second Byte--- (no of registers to read-1)

Third Byte----- 0x00 

But I am unable to read the written value back.I am reading some other value from same register. Hence I am unable to understand where the issue is.

Also is the values read from registers is of 2's complement format or not?

NOTE: RESET bar pin of ADS is held high before performing SPI writes.

Expecting a quick reply.

Thanks and Regards,

Janardan M

 

 

                    

                    

  • Janardan M80 said:
    Expecting a quick reply.

    Such ... proves "SO GOOD" to know.     Might any other "expectations" - serve you - even further?

    Have you considered that your post arrives during a "weekend" - and that (even) highly skilled Vendor Agents - are entitled to (some) respite?     Does your "Expectation" direct the,  "Promotion of your post" - above ALL OTHERS?     (even those arriving prior to yours - which also - are "highly important" to their authors?)

    Those "Expecting" - or claiming "Urgent" - are most likely to induce diametrically opposite response...

    Your posting - otherwise - was "Quite Good" - until that  (ugly/ off-putting)  "Expectation" reared..     With "that said" - follows several comments - in your (no longer expectant) behalf!

    You should "be aware" that (both) "SPI data OUT from the Master"  - and "IN from the Slave" - are "commonly clocked" via the SPI Master.     Thus - the data returned from the Slave - will be valid upon the "next SPI Put" (read via an "SPI GET") and not in "unison w/the SPI PUT" - as your writing (appears) to suggest.

    Your careful charting of SPI Data Received - as returned upon the very next "SPI PUT's clocking" (via SPI GET) should reveal the Slave Device's "Sequenced Pattern of Data Response" - which MUST be one clocking cycle (behind!)      (that so the Slave device has (some) chance to absorb your  "Command or Data Request"  (arriving one SPI PUT cycle earlier) - and  only then, (upon the next "SPI Put")  "Ready & Produce a Response."

  • Hi,

    Thanks for the response, I was not aware that word "Expectation" would annoy someone that much, I am well aware that  using those words would not promote my post. I will make sure not to use those words here on.

    I understand that SPI shares same clock for transmit and receive , it works as virtual ring topology.

    Please find the below timing diagram.

    What I understand from the timing diagram is that I need to send opcode1 , then opcode2 and then I will receive the Register data.

    So  for receiving the register data the clock is to be provided from master hence I sent 0x00 which would initiate clocking. 

    Please find the below code for the reference.

     

    SSIDataPut(SSI0_BASE, RREG|0x01);      // Opcode1
    SSIDataPut(SSI0_BASE, 0x00);                 // Opcode 2
    SSIDataPut(SSI0_BASE, 0x00);                 // Send a dummy data to initiate clocking
    SSIDataGet(SSI0_BASE, &retVal);             // Read Recived data from FIFO

    What I understood is SSIDataGet API fetched the data which is received and placed in FIFO. 

    Is my understanding wrong? does SSIDataGet  API provides necessary clocking to receive data from slave?

    Thanks and Regards,

    Janardan M

     

  • The reasons for, "Expectation's dislike" have been detailed - we have passed beyond that.

    Your diagram is clear - yet properly extracting SPI Data which is (sufficiently) offset (as yours appears) usually requires extra care.     It is normal that following (each) "SPIDataPut()" with an "SPIDataGet()" will serve to your advantage - as "the dummy data" received w/each "SPIDataPut()" may be exhausted via the following, "SPIDataGet()."  

    In your specific case - each "Opcode" sent - will return "dummy" data - thus you'll have 2 dummy data elements to (reject).    Your Slave's data diagram shows, "Desired Data" - commencing upon the "Third SPI Clocking" - which is only generated via your employ of a third, "SPIDataPut()."     And you were (indeed) clever enough to recognize just that.    Yet  the "single" - "SPIDataGet()" you launch - will recover "illegal or dummy data ONLY" - (sent by the Slave during your first, SPIDataPut()) - not the "Reg Data" you desire.    

    I believe that your creating "PAIRED, SPIDataPut() followed by SPIDataGet() transactions" - rather than that,  "3 SPIDataPut() Sequence"  (back to back to back) - will better enable your capture of  the "real/sought" Slave SPI Data.

    It (often) proves best to identify the simplest Slave Register - which enables your, "eased & clear identification" of the Slave's (pardon) "expected and/or listed" Data Response.      By targeting such Register  - w/ "Known & Insured Content"  you "Enhance your recognition" of  "REAL DATA RECOVERY" - as opposed to "Unwanted, Dummy Data."  

    I believe that "KISS" directed - small, focused, measured SPI experimentation (examining SPI Received Data) - will build (both) your confidence & understanding.     Bon chance, mon ami...