TMS320F28335: Problem with SPISTEA signal when operating as master

Deepthi Sivadas

Part Number: TMS320F28335
Other Parts Discussed in Thread: DAC80004

Hi,

I was trying out the loopback with interrupts example given in the module for SPI - Example_2833xSpi_FFDLB_int.c. I have configured GPIO16-19 for SPI operation. There isn't any change in the SPISTE signal at GPIO19. According to the operation manual, SPISTE should be taken low by the master before transmitting and should be driven high after transmission is complete. But the pin GPIO19 just remains low for the entire operation. I could see the clock signal and data from master output pin (18 and 16) using an oscilloscope. As I understand SPISTE signal should be used as chip select for my application.

The configuration of GPIO is given here.

void InitSpiaGpio()
{

   EALLOW;
/* Enable internal pull-up for the selected pins */
// Pull-ups can be enabled or disabled by the user.
// This will enable the pullups for the specified pins.
// Comment out other unwanted lines.

    GpioCtrlRegs.GPAPUD.bit.GPIO16 = 0;   // Enable pull-up on GPIO16 (SPISIMOA)
    GpioCtrlRegs.GPAPUD.bit.GPIO17 = 0;   // Enable pull-up on GPIO17 (SPISOMIA)
    GpioCtrlRegs.GPAPUD.bit.GPIO18 = 0;   // Enable pull-up on GPIO18 (SPICLKA)
    GpioCtrlRegs.GPAPUD.bit.GPIO19 = 0;   // Enable pull-up on GPIO19 (SPISTEA)

/* Set qualification for selected pins to asynch only */
// This will select asynch (no qualification) for the selected pins.
// Comment out other unwanted lines.

    GpioCtrlRegs.GPAQSEL2.bit.GPIO16 = 3; // Asynch input GPIO16 (SPISIMOA)
    GpioCtrlRegs.GPAQSEL2.bit.GPIO17 = 3; // Asynch input GPIO17 (SPISOMIA)
    GpioCtrlRegs.GPAQSEL2.bit.GPIO18 = 3; // Asynch input GPIO18 (SPICLKA)
    GpioCtrlRegs.GPAQSEL2.bit.GPIO19 = 3; // Asynch input GPIO19 (SPISTEA)

/* Configure SPI-A pins using GPIO regs*/
// This specifies which of the possible GPIO pins will be SPI functional pins.
// Comment out other unwanted lines.

    GpioCtrlRegs.GPAMUX2.bit.GPIO16 = 1; // Configure GPIO16 as SPISIMOA
    GpioCtrlRegs.GPAMUX2.bit.GPIO17 = 1; // Configure GPIO17 as SPISOMIA
    GpioCtrlRegs.GPAMUX2.bit.GPIO18 = 1; // Configure GPIO18 as SPICLKA
    GpioCtrlRegs.GPAMUX2.bit.GPIO19 = 1; // Configure GPIO19 as SPISTEA

    GpioCtrlRegs.GPBMUX2.all = 0;       // GPIO63 ... GPIO48 = General Purpose I/O
    GpioCtrlRegs.GPBDIR.bit.GPIO60 = 1;       // GPIO60 as output
    EDIS;
}

The main code is the same as example code given in the module.

over 8 years ago

0 Vincent Rodriguez over 8 years ago

TI__Mastermind 28285 points

Deepthi,

Can you try removing this line?

GpioCtrlRegs.GPBMUX2.all = 0; // GPIO63 ... GPIO48 = General Purpose I/O

You can also check and make sure that SPISTE is being set high correctly during this initialization.

Hope this helps!

Vince Rodriguez

0 Vincent Rodriguez over 8 years ago in reply to Vincent Rodriguez

TI__Mastermind 28285 points

Also, if you are sending multiple words, our SPI does not toggle the SPISTE as long as there is data to transmit.

If you add delays between individual words, you should see SPISTE transition.

VR

0 Deepthi Sivadas over 8 years ago in reply to Vincent Rodriguez

Prodigy 50 points

Hi Vince,

Adding delays did the trick. I was writing two 16 bit words into the TXBUF using FIFO and at the start of TX-ISR I added a delay loop. As I expected, the SPISTE signal toggled for every 32 clock cycles which is what I need for using the DAC80004. Thanks a lot for helping me out.

The ISR for transmission is given here.

__interrupt void spiTxFifoIsr(void)
{
    Uint16 i;
    delay_loop();
    for(i=0;i<2;i++)
    {
        SpiaRegs.SPITXBUF=sdata[i];      // Send data
    }
    SpiaRegs.SPIFFTX.bit.TXFFINTCLR=1; // Clear Interrupt flag
    PieCtrlRegs.PIEACK.all|=0x20;         // Issue PIE ACK
}

Deepthi

C2000™︎ microcontrollers

C2000 microcontrollers forum

TMS320F28335: Problem with SPISTEA signal when operating as master