• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 30 subscribers
  • Views 1480 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.

MISO Line not Working and Chip Select Erratic

Varun Annadi
Prodigy 60 points
Other Parts Discussed in Thread: TM4C123GH6PM

I am trying to test my SPI on my Tiva part and am probing the SPI pins. I notice that the FSS pin is erratically going high and low, though it does behave correctly for the period of interest. Also, my MISO line does not contain any data. I have the MOSI and MISO shorted on my chip and am running the following code, which has been adapted from TI's SPI code.

Suggestions on how to get SPI working correctly would be greatly appreciated. 

#include <inc/tm4c123gh6pm.h>
#include <stdint.h>
#include <stdbool.h>

#include "types.h"
#include "main.h"

#include <inc/hw_memmap.h>
#include <inc/hw_types.h>

#include <driverlib/rom.h>
#include <driverlib/gpio.h>
#include <driverlib/pin_map.h>
#include <driverlib/sysctl.h>
#include <driverlib/systick.h>
#include <driverlib/timer.h>
#include <driverlib/ssi.h>

#include <inc/hw_ssi.h>
#include <inc/hw_gpio.h>

#include "driverlib/rom_map.h"

void main(void)
{
// Set System Clock to 80MHz
SysCtlClockSet(SYSCTL_SYSDIV_2_5 | SYSCTL_USE_PLL | SYSCTL_OSC_MAIN | SYSCTL_XTAL_16MHZ);


//Initializing Ports
SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA); //GPIO Port A: SSI0 to Accelerometer
SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI0); //SSI Peripheral
//SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD); //GPIO Port D
//SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF); //GPIO Port F
//SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOE); //GPIO Port E: LEDs

GPIOPinConfigure(GPIO_PA2_SSI0CLK); //SCLK
GPIOPinConfigure(GPIO_PA4_SSI0RX); //MOSI
GPIOPinConfigure(GPIO_PA5_SSI0TX); //MISO
GPIOPinConfigure(GPIO_PA3_SSI0FSS); //CS_BAR
GPIOPinTypeSSI(GPIO_PORTA_BASE, GPIO_PIN_2 | GPIO_PIN_3 | GPIO_PIN_4 | GPIO_PIN_5);

//GPIOPinTypeGPIOInput(GPIO_PORTD_BASE, GPIO_PIN_0); //INT1 and INT2
//GPIOPinTypeGPIOOutput(GPIO_PORTD_BASE, GPIO_PIN_2); //CELL_TEST
//GPIOPinTypeGPIOInput(GPIO_PORTF_BASE, GPIO_PIN_0); //CELL_READ
//GPIOPinTypeGPIOOutput(GPIO_PORTE_BASE, GPIO_PIN_4); //LED 1
//GPIOPinTypeGPIOOutput(GPIO_PORTE_BASE, GPIO_PIN_5); //LED 2


//Enabling SSI port
SSIDisable(SSI0_BASE);
SSIClockSourceSet(SSI0_BASE, SSI_CLOCK_SYSTEM);
SSIConfigSetExpClk(SSI0_BASE, SysCtlClockGet(), SSI_FRF_NMW, SSI_MODE_MASTER, 5000000, 8);
SSIEnable(SSI0_BASE);

//Default States for Ports
//GPIOPinWrite(GPIO_PORTD_BASE, GPIO_PIN_2, LO); //Setting CELL_TEST low

unsigned int ulDataTx;
unsigned int ulDataRx;
//unsigned int ulindex;


while(SSIDataGetNonBlocking(SSI0_BASE, &ulDataRx))
{
}

ulDataTx = 5;

SSIDataPut(SSI0_BASE, ulDataTx);

while(SSIBusy(SSI0_BASE))
{
}

SSIDataGet(SSI0_BASE, &ulDataRx);

while(1)
{

while(SSIDataGetNonBlocking(SSI0_BASE, &ulDataRx))
{
}

ulDataTx = 5;

SSIDataPut(SSI0_BASE, ulDataTx);

while(SSIBusy(SSI0_BASE))
{
}

SSIDataGet(SSI0_BASE, &ulDataRx);

}


}

  • 0
    TI__Genius 10610 points

    Varun,

    I ran your code and was unable to duplicate the erratic behavior you are seeing with the chip select/enable signal.  However, I did notice that you switched the MOSI and MISO labels in your comments.  SSI0RX (receive) should be MISO (master in, slave out) and SSI0TX (transmit) should be MOSI (master out, slave in.)  Perhaps this will resolve the issue with the MISO line does not containing any data.

    If this does not fix your problems, please give me more information about your hardware setup.

    Best regards,

    Daniel

  • 0 in reply to daniel_o
    Prodigy 60 points

    Daniel, 

    Thank you for catching the mis -labeling of the MISO MOSI lines. I was, however, probing the correct pins on the micro, so the MISO line is still not working correctly. 

    For my set up, I have a ldo generating a 3.3 V rail to power the TIVA series TM4C123GH6PM Micro. I also have transient and bulk caps at all 3.3 rails. Finally, I have a 16MHz crystal connected to the micro. Though my board has pads for many other components, I have not populated any of them because I can not get the SPI to work. 

    I short my MOSI and MISO pins and run the code in the previous post. As I mentioned before, the chip select, though low when I am transmitting data, does not remain high for the remainder of the time. It randomly goes up and down. In addition, I do not see any information come in on the MISO line. 

    Do you have any suggestions?

    Thanks!

  • 0 in reply to Varun Annadi
    TI__Genius 10610 points

    Varun,

    Is there any particular reason you are using Microwire (SSI_FRF_NMW) mode instead of a standard SPI mode (i.e, SSI_FRF_MOTO_MODE_0 or similar)?  I think this may be the root of the problems you are having as microwire behaves differently than SPI.

    -Daniel

  • 0 in reply to Varun Annadi
    Guru 117855 points

    Varun Annadi said:
    Though my board...pads...many...components, not populated any of them because I cannot get the SPI to work. 

    Facts in evidence point to your custom board - and you appear to "start" your testing via a lesser known SPI mode.  Unique - but perhaps not especially sound. 

    Perhaps better to "liberate" that port from its SSI default - and test/verify that you can output from each pin when config'ed as GPIO - not SPI.  Upon success - switch the MISO pin from GPIO Output to GPIO Input - and drive from MOSI which is still config'ed as GPIO Output.  This will - at minimum - confirm that your custom board can generate basic I/O - and "sets the stage" for a relaunch of your desired SPI test.

    Your MCU has 2 NMI pins - and if they float "high" - might NMI be triggered?  (and erratically)

    How about Reset - is it "unpopulated."  (quote, "not populated any of them!") 

    And - silent is your routing/interconnect/attachment of any Port A "SPI" pin.  Routing is not covered via your "not populated" - and signal routing into too low an impedance (i.e. a pin which may be config'ed as output) would explain your loss of signal level.)  We're left to guess as data provided is insufficient (perhaps itself - erratic...)

    Troubleshooting any custom board - when supporting data is "suspect/minimal" - is not shortest/best path toward solution...

    And - as you report a custom board - had you earlier employed a factory board - built your skills/SW expertise upon that - and then attempted your custom board?

  • 0 in reply to cb1_mobile
    Prodigy 60 points

    Thank you everyone! I found that I was not grounding my scope, hence why my signals were erratic.