CCS/TMS320C5515: Changing CS0 to CS1

Hi Ferhat,

Are you by chance using the ECG board on the C5515 EVM? If not, this may a little confusing...

The LLC_SPI_SlaveSelect routines were written for the medical development kit (MDK) which was discontinued years ago.

Any how, I suspect that the EBSR parallel port pinmux mode used does not route SPI_CS1 out from the C5515 DSP.

I dug up the old MDK software and found that the default pin mux setting is for Mode 5, which only routes SPI_CS0 and does not route SPI_CS1.

Do you see any code like this in your software? This sets the PPMODE of the EBSR register to MODE 5.

    CSL_FINS((*PERIPHSEL0_ADDR),PERIPHSEL0_SEL_PARALLELPORT, 0x5);

One catch, however, is that if you are using the C5515 EVM, that board routes only the SPI signals from Mux mode 5 to the analog front end headers (J10, J13, J14). The mux mode 6 SPI signals are routed to the P1 and J19 (the LCD ribbon connector). Unfortunately, SPI_CS0 is not routed to the P2 header...

So you can use SPI in Mux Mode 5 with SPI_CS0 at J13 (and SPI_CS1 not routed from the DSP), or you can use SPI in Mux Mode 6 with SPI_CS0 as well as CS1-3 all routed to the J19 LCD ribbon connector.

Hope this helps,
Mark

Hello Mark, thanks for reply.

I have my own board.

Im already using Mode 5, SPI and Uart, they are working fine.

I communicate with ADS with CS0. Its fine.

I have a memory on same SPI. Its CS pin connectod to GPIO pins, it also works fine when i remove ADS.

Problem is i have to change to CS1 in any time while applicaton runs. So ADS wont response and i can communicate with memory truly.

Now it corrupts from ADS and Memory. Both responses when i try to read memory, i have to stop ADS, memory no problem, its CS pin is GPIO.

I read sprufo3, i tried many thing but all stops or starts not working well.

I see register changes SPICMD2 CSNUM truely.

I changed by register directly  or used methods from SDK below.

if i do only deselect CS0 periodicaly with  LLC_SPI_SlaveSelect(0);  CS0 stays always low.

I tried LLC_SPI_SlaveSelect(1);  than LLC_SPI_SlaveSelect(0); spi all stops working.

Ferhat

Still i need help.

Hi Ferhat,

Sorry the E2E was having login problems.

I just tried the CSL_SPI_Example (download CSL here: http://software-dl.ti.com/dsps/dsps_public_sw/dsps_swops_houston/C55X/latest/index_FDS.html)

This example uses EBSR PPMODE 3, which for SPI is equivalent to MODE 5.

I changed the example to use CS1, which is not available in MODE 3/5

CSL_SPI_Example_Out/spi_eepromApi.c @ line 127

From                     CSL_SPI_REGS->SPICMD2 = (Uint16)0x0039;  //  8-bit words, read

to                            CSL_SPI_REGS->SPICMD2 = (Uint16)0x1039;  //  8-bit words, read, force CS1…   

When I ran the EEPROM test with this modification, I did not observe CS0 go low, and the EEPROM did not respond to the SPI traffic.

I suspect your problem is that you have 2 chip selects low at the same time. Just before you write/read with SPI, halt the program and read the SPICMD2 register to verify that CSNUM field is not set to 0 for CS0.

Maybe your software is changing CSNUM back to 0 for you. I am not so familiar with those LLC_SPI_SlaveSelect software routines. Can you try running the CSL SPI examples to see if you can debug your problem?

I also tried toggling PD9PD in PDINHIBR3 which enables the internal pull-down on SPI_CS0 (MODE3/5), but the CS0 pin stayed high. I typically recommend a pull-up on CS to avoid it going low when in high-impedance state, which may corrupt things. I don’t expect this is your problem though.

If you wanted to get aggressive, you could use that GPIO to also drive a tri-state buffer that only passes SPI_CS0 to the ADS when GPIO is high. In that case, you will definitely need a pull-up at SPI_CS of the ADS…

Hope this helps,
Mark