'SPI master read function' on TIVA C TM4C123G.

Hi, Amit Ashara,

This is the sequence to read one byte?

- SSIDataPut(SSIn_BASE, REG_ADD);

- SSIDataPut(SSIn_BASE, DUMMY);

- SSIDataGet(SSIn_BASE, &value);

I'm trying this, to read from 0x00 register in MAX31865, but doesn't work!

It is right?

    SSIDataPut(SSI0_BASE, 0x00);
    //
    // Wait until SSI0 is done transferring all the data in the transmit FIFO.
    //
    while(SSIBusy(SSI0_BASE))
    {
    }

    //SysCtlDelay(80000);

    SSIDataGet(SSI0_BASE, &data);

    SSIDataPut(SSI0_BASE, 0xFF);

    while(SSIBusy(SSI0_BASE))
    {
    }

    SSIDataGet(SSI0_BASE, &data);

qi wang said:

I have finished the 'master write function'. It works well.

May we ask, "How you came to that "works well" conclusion?"     You provide no supporting data for, "working well" - yet "DO" supply "evidence to the contrary" (failed SPI reads!)    (as those "reads" may only result from the earlier arrival of "proper" SPI Writes!)     Such is, "within the realm of possibility" - is it not?

Poster Robert (properly) asks for "earlier, vital, related code!"    While presently withheld - your selection of a, "mismatched SPI format" - is likely to "DOOM" all of your subsequent efforts!   And that "critical" code is NOT present.    Note that "view of a scope trace(s)" provides incomplete assurance that SPI Writes are properly formatted - unless you have carefully reviewed the Slave device's requirement - and the two "match."

No information is presented re:

• proper powering of your slave device
• your checks for continuity between all connections - slave & MCU
• the separation distance between slave & MCU
• presence of noise sources, high speed digital signals, local RF/cell/tablets
• proper ESD discipline - both at/around the MCU and Slave device

The award of "working well" - in absence of most (perhaps all) of the above - may well be "premature."

As a "guide" to you/others - SPI Transmission/Writes may be judged as "working well" when:

• the MCU's: SPI clock, CS, & MOSI all (properly) match the MCU's Timing/Signal Diagram - for that particular SPI Format
• that particular SPI Format "matches" the requirement imposed by the SPI Slave.   (the Slave is the "Boss of (me) and the MCU" - as the Slaves (usually) are less (format) flexible than the MCU)
• users have "reasonably" complied w/the "5 point "laundry list" (above)"

Hello cb1,

Please note that qi wang - the original poster - went silent after his request, and Allef, the new poster, is the one making the new request. So the situations are not related.

Greetings Ralph,

Good grief - you are correct.    (I'm (now) guilty of the (same) fault I've noted by vendor staff!)

Yet - your claim, "situations are NOT related" - may in fact be incorrect!    The new poster reports a "NEAR IDENTICAL" inability to read SPI - does he not?     How then - are the "situations NOT related?"

While my "quote" proves improper - is not ALL ELSE - especially ALL ELSE - fully focused & proper?

(i.e. we find no presentation of "SPI format selection" and thus (still) our (NEWLY ARRIVING) poster's SPI Write (may) prove suspect.    Is that not true?)

The guidelines I've provided (still) hold true - and of good value - are they not?

My "poster targeted error" thus may not be (especially) significant - yet is acknowledged - and my "outsider efforts" will be more disciplined...

Again - the situations - when properly/fully considered - are HIGHLY RELATED - are they not?     (the desire to "find outsider fault" may have caused "over-reaction" mais oui?)

Thank you - although it MUST be stated - there is "MUCH HIGHLY RELATED" between each poster's issue!    (Neither can "Read via SPI - how possibly is that NOT RELATED?)

The earlier, "NOT RELATED" comment is far "off mark" - overly critical - and as NO VENDOR AGENT had made the time/effort to assist (the new poster) - highly unwarranted!

Hi, all!

I don't have an oscillope at this moment. But with a multimeter I can see the voltage and continuity as expected.

Also, I have tried forcing and without force the Fss.

I know I'm trying to connect with a very specific device, but I just need to validate the read operation for one byte in SPI.

There is some stupid mistake in this code?

#include <stdbool.h>
#include <stdint.h>
#include "inc/hw_memmap.h"
#include "driverlib/gpio.h"
#include "driverlib/pin_map.h"
#include "driverlib/ssi.h"
#include "driverlib/sysctl.h"
#include "driverlib/uart.h"
#include "utils/uartstdio.h"


uint32_t data;

void main(void)
{
    uint32_t ui32SysClock;

    // I don't have a crystal
    ui32SysClock = SysCtlClockFreqSet((SYSCTL_OSC_INT | SYSCTL_USE_PLL |
                                            SYSCTL_CFG_VCO_480), 120000000);


    // Enable Multiplexer CH4
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOK);
    GPIOPinTypeGPIOOutput(GPIO_PORTK_BASE, GPIO_PIN_5 | GPIO_INT_PIN_6);
    GPIOPinWrite(GPIO_PORTK_BASE, GPIO_INT_PIN_5, ~0);
    GPIOPinWrite(GPIO_PORTK_BASE, GPIO_INT_PIN_6, ~0);


    //
    // The SSI0 peripheral must be enabled for use.
    //
    SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI0);

    //
    // For this example SSI0 is used with PortA[5:2].  The actual port and pins
    // used may be different on your part, consult the data sheet for more
    // information.  GPIO port A needs to be enabled so these pins can be used.
    // TODO: change this to whichever GPIO port you are using.
    //
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);

    //
    GPIOPinTypeGPIOOutput(GPIO_PORTA_BASE, GPIO_PIN_3);
    //

    //
    // Configure the pin muxing for SSI0 functions on port A2, A3, A4, and A5.
    // This step is not necessary if your part does not support pin muxing.
    // TODO: change this to select the port/pin you are using.
    //
    GPIOPinConfigure(GPIO_PA2_SSI0CLK);
    //GPIOPinConfigure(GPIO_PA3_SSI0FSS);
    GPIOPinConfigure(GPIO_PA4_SSI0XDAT0);
    GPIOPinConfigure(GPIO_PA5_SSI0XDAT1);

    //
    // 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
    //      PA2 - SSI0CLK
    // TODO: change this to select the port/pin you are using.
    //
//    GPIOPinTypeSSI(GPIO_PORTA_BASE, GPIO_PIN_5 | GPIO_PIN_4 | GPIO_PIN_3 |
//                   GPIO_PIN_2);
    GPIOPinTypeSSI(GPIO_PORTA_BASE, GPIO_PIN_5 | GPIO_PIN_4 | GPIO_PIN_2);

    //
    // SPI Mode 3 for MAX31865
    //
    SSIConfigSetExpClk(SSI0_BASE, ui32SysClock, SSI_FRF_MOTO_MODE_3,
                       SSI_MODE_MASTER, 1000000, 8);

    //
    // Enable the SSI0 module.
    //
    SSIEnable(SSI0_BASE);


    //
    // Read any residual 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, &data))
    {
    }

    GPIOPinWrite(GPIO_PORTA_BASE, GPIO_PIN_3, ~0);

    for(;;) {
        //
        // Send the data using the "blocking" put function.  This function
        // will wait until there is room in the send FIFO before returning.
        // This allows you to assure that all the data you send makes it into
        // the send FIFO.
        //

        GPIOPinWrite(GPIO_PORTA_BASE, GPIO_PIN_3, 0);
        SSIDataPut(SSI0_BASE, 0x01);
        //Depois de enviar tudo
        //
        // Wait until SSI0 is done transferring all the data in the transmit FIFO.
        //
        while(SSIBusy(SSI0_BASE))
        {
        }

        //SysCtlDelay(80000);

        SSIDataGet(SSI0_BASE, &data);

        SSIDataPut(SSI0_BASE, 0xFF); //Dummy

        while(SSIBusy(SSI0_BASE))
        {
        }

        SSIDataGet(SSI0_BASE, &data);

        GPIOPinWrite(GPIO_PORTA_BASE, GPIO_PIN_3, ~0);

        //
        // Since we are using 8-bit data, mask off the MSB.
        //
        SysCtlDelay(60000000);
    }
        //
        // Return no errors
        //

}

Allef Silva28 said:

I don't have an oscillope at this moment.

You need that, or at least a logic analyzer to verify the output.

Allef Silva28 said:

There is some stupid mistake in this code?

Well, I don't have any info on your device (cb1's advice here is valid, start with something simple, like an FRAM or a shift register) but some possibilities are

• chip select
• clock speed
• phasing/mode

How do you know this isn't working? I don't see you checking your data anywhere.

Robert