• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 2 answers
  • Subscribers 99 subscribers
  • Views 1412 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

SPI_1 interface on C6748, glitch on CS[0] line

JohnL
Prodigy 225 points
Other Parts Discussed in Thread: OMAPL138

I am using the SPI_1 interface on the C6748.  The PinMux() is correctly configured.  All the four lines are active, CS[0], clk, somi and simo, and responding according to the spec.

I would like to use the chip select CSHOLD in the SPIDAT1 transmit register.  The CSHOLD works correctly except that there is a glitch on the CS line at the end of the first transfer.  This glitch causes the SPI slave to not respond with data.  See image below.  The traces from top to bottom are, CS[0], clk, somi and simo.

#define CS_HIGH   (0x01)
#define CS_LOW   (0xFE)

SPIDat1Config(SOC_SPI_1_REGS, (SPI_CSHOLD |  SPI_DATA_FORMAT0), CS_LOW);
SPIDefaultCSSet(SOC_SPI_1_REGS, CS_HIGH);
// order is c2edelay, t2edelay, t2cdelay, c2tdelay
SPIDelayConfigure(SOC_SPI_1_REGS, 0, 0, 100, 100);

CS_HIGH and CS_LOW can also be set to 0x01 and 0x00, but the behaviour is the same.

An external pulldown resistor on the CS[0] line does not make a change.

Various settings of the delay values does not make a change.

All the various Ti literature shows that the CSHOLD setting in the SPIDAT1 register is correct, for example;

Configuring SPI_CS Polarity

There is no single bit in the SPI registers which allows you specify the polarity of the SPI_CS pin(s).  However, there are two register fields that allow you to specify the state of the SPI_CS pins when a data transfer is active and when there is no data transfer.  The SPIDEF.CSDEF bits define the state of the SPI CS pins when there is no data transfer ongoing: 0 means set the pin low and 1 means set the pin high.  Similarly, the SPIDAT1.CSNR bits define the state of the SPI CS pins when there is a transfer ongoing: 0 means set the pin low and 1 means set the pin high.  Each bit in CSNR and CSDEF corresponds to a CS pin supported on the device.  For example, CSNR[0] corresponds to SPI_CS0, CSNR[1] to SPI_CS1, etc.  In the case your device only supports one CS pin, only bit 0 of these bit fields applies.  If you want the SPI.CS0 pin to be active low, you want to have CSDEF[0] = 1 and CSNR[0] = 0.

from http://processors.wiki.ti.com/index.php/Using_SPI_Chip_Select_Pin_on_C674x/OMAP-L1x

QUESTION

Note the glitch on the CS[0] line.  Why is the C6748 SPI_1 interface doing this?

if the CS[0] line is instead configured as a GPIO line and the CS line is controlled externally, the CS[0] line behaves correctly.  See the image below.

Note there is no glitch on the CS[0] line and the SPI slave responds correctly.

John

  • 0
    TI__Guru** 116100 points
    Dear John,
    It would be useful if you reproduce the issue in any of our EVM boards.
    LCDK board, OMAPL138 LogicPD EVM and OMAPL138 Spectrum digital EVM board.
  • 0
    Guru 26430 points
    The TRM would suggest that CSHOLD is self clearing. Is your code using interrupt, dma or polled IO? With polled IO, you may need to call SPIDat1Config() before each SPITransmitData1(). StarterWare has interrupt and edma examples that appear to handle CS hold properly without calling SPITransmitData1(). Some weirdness there.
  • 0 in reply to Norman Wong
    Prodigy 225 points

    Norman,

    Thanks for your post, this was helpful.

    The problem occurred, because I set up a loop to view the SPI transactions on the scope, but failed to see that the very first SPI transaction worked correctly. 

    My test routine is using interrupts and on the last SPITransmitData1() CSHOLD is cleared, but the routine failed to reset the CSHOLD bit at the start of the next transaction.

    So now the SPIDat1Config(CSHOLD) is called before each transaction request is initiated, and SPIDat1Config() is called before the last byte which clears the CS line.  Works perfectly.  Thanks again.

    John

  • 0 in reply to JohnL
    Guru 26430 points
    Since you were able to call SPIDat1Config() before the last byte in the interrupt code, it implies that under certain conditions, clearing the CSHOLD bit does not immediately change the CS. The CS is changed after the data has finished transmitting. Results in CS changing immediately after the last data byte. Tight precise timing.

    The StarterWare interrupt example has the SPIDat1Config(CSHOLD) at init and prior to transfer. It has SPIDat1Config() after the last byte in mainline code. Not in the interrupt code. In this case, it seems clearing the CSHOLD bit immediately changes the CS. Otherwise the code would not work for more than one transaction. Assuming it does work. Maybe it doesn't and there is a bug. If it does work, the CS deasserts some time after the last byte due to the time it takes the mainline code to notice that the interrupt code has finished.

    Anyhow, please mark your post as solved to close out the thread.
  • 0 in reply to Norman Wong
    Prodigy 225 points
    Norman,
    The SPIDat1Config() now works according to the spec. This is just a test routine for me to get the code operating with the tight timing requirements that is needed to communicate with a slave device. Clearing the CSHOLD bit in the interrupt routine provides the precise timing for the clearing of the CS, which the slave device requires.
    John
  • 0 in reply to JohnL
    Prodigy 225 points
    Norman, not sure if I marked it is solved properly.
  • 0 in reply to JohnL
    Guru 26430 points
    I don't know the etiquette for marking posts solved. Mustbe a tread around somewhere on that. Having a post marked as solved gives some extra "points" to the author of the post. My opinion is that if a post helps solve your problem, mark that guys post as solved. If you solved the problem yourself, mark you own post as solved. In this thread, you pretty well solved your own problem. Marking my posts was generous. You can "unsolve" posts if you like. I am not much one to chase points. More concerned about the green mark on ther thread that helps the TI guys manage their time.
  • 0 in reply to Norman Wong
    TI__Guru** 116100 points
    Dear Norman and John,
    Apologize.
    Actually I've put verified for both posts, as I understand using Norman's point John was able to find out the problem, so I'd put verified for the both good answers.
    Sorry if that disturbed you.

    Thanks again Norman for supporting the community members.
  • 0 in reply to Titusrathinaraj Stalin
    Prodigy 225 points

    Titus,

    All ok.  I'm happy to have it resolved.

    John