• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 97 subscribers
  • Views 634 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.

problem with spi interface on TMS320DM648 dsp

giuliop
Prodigy 40 points
Other Parts Discussed in Thread: TMS320DM648

Hi all,
I have a Lyrtech EVMDM648 equipped with a TMS320DM648 dsp, and I need to write a SPI interface between the dsp and a SPI EEPROM (ATMEL730 25256A).
The board mux settings (not the DSP mux settings) between UART and SPI are surely correct (I had to turn off a dip switch); furthermore, i verified
that the EEPROM has to be configured in MSB-first shift mode.
The code that I wrote in CCS to configure SPI interface is the following:

    PINMUX |= (1 << 12);     // SPI enable on PINMUX
    PINMUX &= (0xFFFFDFFF)     // UART disable on PINMUX

    SPIGCR0 = 0; // reset SPI peripheral
    SPIGCR0 = 1; // remove reset from SPI peripheral

    SPIGCR1 = 0x00000003;  // enable clock mode and master bits

    SPIPC0  = 0x00000E01;  // enable SPIDI, SPIDO, SPICLK, SPICS0

    SPIFMT1 = 0x00000008; // configure WORD LENGTH = 8 bit
                                        // configure MSB-first shift mode
                                        // configure POLARITY = 0, PHASE = 0

    SPIFMT1 |= (0x13 << 8) // configure CLK_PRESCALE = 0x13, to obtain a SPI_CLOCK = 7.5 MHZ;

    SPIDAT1 = 0x00020000;   // select SPICS0 only
    SPIDAT1 |= (1 << 24);     // selecting DATA_FORMAT 1
    SPIDAT1 |= (1 << 28);     // selecting CSHOLDMODE

    SPIGCR1 |= (1 << 24);     // SPIEN enable

The problem is: when I write a RDSR command (Read Status Register, value = 5) in the shift register, like this:

    SPIDAT1 |= 5;

I always get an 0xFF value, as if the pins were in high impedance state.
Can you help me please?  Do you think configuration is correct?

Thanks in advance

Giulio

  • 0
    TI__Guru 64480 points

    There are a couple of methods to control the UART/SPI on the board.  One is the DIP switch you mentioned before (ie. SW3.6) but also from the MSP430 on the board.  You might want to make sure they both agree to configure UART/SPIn=0.

    From the DM648 EVM documentation, it appears the MSP430 configures U47.18 low which is UART/SPIn.

    At first glance, it appears the settings are correct, but if you could monitor the signal on the board to see if it is in fact toggling, that would help isolate the issue.

  • 0 in reply to BrandonAzbell
    Prodigy 40 points

    Thank you for your reply :)

    BrandonAzbell said:

    There are a couple of methods to control the UART/SPI on the board.  One is the DIP switch you mentioned before (ie. SW3.6) but also from the MSP430 on the board.  You might want to make sure they both agree to configure UART/SPIn=0.

    I forgot to tell you that I'm using both configuration modes just to be sure that SPI is enabled. I'm using Lyrtech library to tell the MSP430 to enable SPI and disable UART.

    I just verified that without turning off the DIP switch (SPI off) and without configuring MSP430 (so, again, SPI off), I obtain the same result (0xFF while reading the status register).

    BrandonAzbell said:

    From the DM648 EVM documentation, it appears the MSP430 configures U47.18 low which is UART/SPIn.

    At first glance, it appears the settings are correct, but if you could monitor the signal on the board to see if it is in fact toggling, that would help isolate the issue.

    For now I can't know, because I'm working at home and I don't have an oscilloscope :( I hope I can soon isolate this issue that is driving me crazy!

    Giulio

     

     

     

     

     

  • 0
    TI__Mastermind 18130 points

    When you OR the value of 0x5 into SPIDAT1 what guarantee do you have that the lower 16 bits are not already 0xFFFF? Note the following from the SPIDAT1 field description on page 29 of the SPI User Guide:

    When data is read from this field, the value is indeterminate because of the shift operation. The value in the SPI buffer register (SPIBUF) should be read after the shift operation is complete to determine what data was shifted into SPIDAT1.


    You might be better off making a 16-bit pointer to the lower 16 bits of SPIDAT1 and hard-write the value you wish to send out. For example, declare SPIDAT1_16 as a short pointer and then write SPIDAT1_16 = 5;

    Also, it looks like you at least followed most of the initialization steps in the SPI User Guide, but you may want to walk through 2.6.2 in the User Guide to ensure that you did not skip any of the configuration steps.

  • 0 in reply to giuliop
    Prodigy 40 points

    Hi Tim, thanks for your help.

    Now the code is the following, but I couldn't solve the problem, because the result is always 0xFF :

    PINMUX |= (1 << 12);     // SPI enable on PINMUX
    PINMUX &= (0xFFFFDFFF)     // UART disable on PINMUX

    SPIGCR0 = 0; // reset SPI peripheral
    SPIGCR0 = 1; // remove reset from SPI peripheral

    SPIGCR1 = 0x00000003;  // enable clock mode and master bits

    SPIPC0  = 0x00000E01;  // enable SPIDI, SPIDO, SPICLK, SPICS0

    SPIFMT1 = 0x00000008; // configure WORD LENGTH = 8 bit
                                            // configure MSB-first shift mode
                                            // configure POLARITY = 0, PHASE = 0

    SPIFMT1 |= (0x31 << 8) // configure CLK_PRESCALE = 0x31, to obtain a SPI_CLOCK = 3 MHZ;

    SPIDAT1_HIGH = 0x0002; // selecting SPICS0 only

    SPIDAT1_HIGH |= (1 << 8); // selecting DATA_FORMAT 1

    SPIDAT1_HIGH |= (1 << 12); // enable CSHOLD

    SPIDAT1_LOW = 0;

    SPIDEF = 0x00000001; // drive SPICS0 high when no transmission is in progress

    SPIGCR1 |= (1 << 24);     // SPIEN enable

    SPIDAT1_LOW = 5;

    I have another question: why SPIPC1 (that should drive pin direction) is not documented in spruem2 and, however, is always 0?

    Thanks again

    Giulio

     

     

     

  • 0 in reply to giuliop
    TI__Mastermind 18130 points

    I am not sure about the SPIPC1 register. I will have to look into this.

    What device are you communicating with on the SPI bus? How long after writing to the shift register do you read SPIDAT1 back? Are you confident that there is not a read of 0xFF occurring at the same time? Have you looked at any of the Rx registers (in SPIBUF)? It would really be beneficial if we knew whether or not any of the SPI signals were toggling as Brandon suggested. Is there no way to check any of these pins?

    Lastly, just in case you were not already aware there is actually a SPI driver in the PSP for DM648. You can find it in the C:\dvsdk_1_10_00_27_DM648\pspdrivers_1_10_00_09\packages\ti\sdo\pspdrivers\drivers\spi directory.

  • 0 in reply to TimHarron
    Prodigy 40 points

    Hi,

    finally there are some good news. First of all, we discovered that SPI signals toggle correctly; furthermore, using oscilloscope, we could identify some problems, like the mismatch in polarity-phase configuration between dsp and eeprom (the 0-0 configuration is not equal: 0-1 in DSP matches 0-0 in EEPROM.. even if I don't know why).

    Finally, we could send a WREN command and a RDSR command correctly: the result was not 0xFF anymore, but 0x02 :). Now I'm trying to write and read a value from the same address: the results are still not good, but for now I'm satisfied :)

    Thank you for the help

    Giulio

  • 0 in reply to giuliop
    TI__Mastermind 18130 points

    giuliop said:
    I have another question: why SPIPC1 (that should drive pin direction) is not documented in spruem2 and, however, is always 0?



    I came across the answer to this and wanted to get it published. The SPIPC1 register is used to set the direction of the SPI pins when they are in GPIO mode. When in SPI mode, the SPI is configured as master or slave.

    Because the SPI pins are not muxed with GPIO on DM648 the SPIPC1 register does nothing (which is why it always appears as 0). The datasheet will be updated to reflect this.