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.

TMS320C5515 SPI funny behaviour

Other Parts Discussed in Thread: TMS320C5515

Hi all,

I am working on TMS320C5515 EVM, and programing it from CCS v6.1.3. I am initializing SPI module correctly, but I get some extra signals, and I am not sure what to think about it. This is my program:

SYS_EBSR=0x5A3F;

SYS_GPIO_DIR0=0xFFBF;
SYS_GPIO_DATAOUT0=0x0802;

for (delay1=0;delay1<3;delay1++);

SYS_GPIO_DATAOUT0=0x0800;

for (delay1=0;delay1<3;delay1++);

SYS_GPIO_DATAOUT0=0x0802;

//SPI
SYS_PCGCR1=0x0000;
for (delay1=0;delay1<3;delay1++);

SYS_PCGCR2=0x0000;
for (delay2=0;delay2<3;delay2++);

SYS_PSRCR=0x0020;
SYS_PRCR=0x0080;
for (delay3=0;delay3<3;delay3++);


SYS_GPIO_DATAOUT0=0x0802;
for (delay3=0;delay3<3;delay3++);
SYS_PCGCR1=0x0000;
SPI_SPICCR=0x0000;
SPI_SPICDR=0x000C;
SPI_SPICCR=0x8000;
SPI_SPIDCR1=0x001C;
SPI_SPIDCR2=0x0303;
//Slanje SDATA
do{

for (delay3=0;delay3<50;delay3++);

SPI_SPIDAT1=0x0000;

SPI_SPIDAT2=0x2100;
SPI_SPICMD1=0x4000;
SPI_SPICMD2=0x003A;
for (delay3=0;delay3<50;delay3++);
//--------------------------------

busy_value1=0;
do{
busy_value=SPI_SPISTAT1;
busy_value1=(busy_value & 0x0001);
}while(busy_value1!=0);
for (delay3=0;delay3<50;delay3++);

}while(1);

So this program initializes SPI module (and some GPIO pins, that Im using for my project) and then it sends 8 bits (0x21=00100001).

And in the next two pictures you can see that besides desired signals, there is another one whose falling edge matches the falling edge of CS signal. I am working on a project where I cant use CS pin, but I will have to use one of the GPIO pins as a chip select, so this extra signal could be a problem. My question is, how do I get rid of this?  

  • Hi Darko,

    There was a similar post on this topic of SPI_TX state outside of SPI transfers: e2e.ti.com/.../1779978

    We found that the SPI_TX signal goes Hi-Z whenever no data is being transferred, or more specifically, whenever SPISTAT2 CCNT is zero - it is driven when CCNT is non-zero.

    On my C5515 EVM while running the CSL SPI EEPROM example, the SPI_TX signal stays outside of SPI transfers. During this time SPI_TX is Hi-Z and I can touch with my finger and see noise on the signal. I can also pull SPI_TX up to 3.3V through a pull-up resistor which proves it is Hi-Z
    But for you it seems to be floating high instead of low. Perhaps you can try a couple of things...
    1) add a pull-down resistor to SPI_TX so that outside of transfers, it goes low
    2) if that doesnt work, try to figure out what is causing the SPI_TX signal to go high outside of transfers... on the C5515 EVM, it is also connected to the AIC3254 codec as I2S2_DX as well as the SPI EEPROM as SPI_TX
    3) See if running the CSL SPI_EEPROM example makes SPI_TX go low between transfers, then study the differences to your code - download CSL here: http://www.ti.com/tool/sprc133
    4) try to hack the software so that SPISTAT2 CCNT is non-zero and SPI_TX remains driven low as if mid transfer - I'm not sure exactly how you can fool the SPI peripheral to keeping CCNT non-zero though. Maybe by making the character length greater than what you require? Or using the word length?

    Since you are using EBSR PPMODE mode 5, only a single SPI chip select, SPI_CS0 is muxed. I see in your code that you are setting up CS2 and CS3 in SPI_SPIDCR2... These chip selects are not muxed out when using PPMODE 5, so I wonder if these settings make any difference. Probably not...

    Normally, a SPI device like an EEPROM will ignore the SPI_TX data until the chip select is active and the SPI CLK latches in the data. So even if the SPI_TX is high when CS becomes active, the SPI_CLK has not latched in any data yet, so that high state of SPI_TX should not matter. Why does your application require SPI_TX to be low before the SPI_CLK starts anyway?

    Hope this helps,
    Mark