TMS320F28377D: SPIDAT always be 0

Hi Ben,

The easiest way to observe if there are any obvious issues with communication is to use an oscilloscope to view the activity on all 4 SPI lines. Are you able to scope these out so we can see if something is amiss? 

Also, the code you attached has a lot of commented out sections - just want to be sure I understand where are you initializing the SPI module? I see a separate function for FIFO initialization but I don't see where you are resetting and re-enabling the SPI module in the procedure documented in the device TRM section 18.4.2 Configuring the SPI. 

Best Regards,

Allison

Hi Allison,

Okay, but my SPI settings were changed under the routines on the TI official website. And it is also set up according to this document. I just checked it again and it seems to be consistent with the process in Chapter 18.

The only question is, is the SPI routine on our official website 28377d what I posted above? I see that in the link you gave, a routine location is given in TRM 18.5.1, but I did not find the path here. You can see that the naming of the routine here is different from the one I downloaded. This is spi_ex1_loopback.c, mine is spi_loopback_cpu1

The following are the settings of my spi.c file. It seems that the process is the same as the settings in 18.4.2. The only difference is that OVERRUNFLAG and INTFLAG are not set to 0 separately, but according to the manual, these two flags will be cleared when SPISWRESET is set to 0, so they have been set to 0, and even if these two flags are set to 0, statement, the problem that the data in SPIDAT is 0 has not disappeared.

Do you think there is a problem with my spi.c settings? If not, what other settings might affect SPI? (In fact, I haven’t touched the settings in other places, they are all routine settings)

//###########################################################################
//
// FILE:   F2837xD_Spi.c
//
// TITLE:  F2837xD SPI Initialization & Support Functions.
//
//###########################################################################
// $TI Release: F2837xD Support Library v210 $
// $Release Date: Tue Nov  1 14:46:15 CDT 2016 $
// $Copyright: Copyright (C) 2013-2016 Texas Instruments Incorporated -
//             http://www.ti.com/ ALL RIGHTS RESERVED $
//###########################################################################

//
// Included Files
//
#include "F2837xD_device.h"
#include "F2837xD_Examples.h"

//
// Calculate BRR: 7-bit baud rate register value
// SPI CLK freq = 500 kHz
// LSPCLK freq  = CPU freq / 4  (by default)
// BRR          = (LSPCLK freq / SPI CLK freq) - 1
//
#if CPU_FRQ_200MHZ
#define SPI_BRR        ((200E6 / 4) / 500000) - 1
#endif

#if CPU_FRQ_150MHZ
#define SPI_BRR        ((150E6 / 4) / 500000) - 1
#endif

#if CPU_FRQ_120MHZ
#define SPI_BRR        ((120E6 / 4) / 500000) - 1
#endif

//
// InitSPI - This function initializes the SPI to a known state
//
void InitSpi(void)
{
    // Initialize SPI-A
    SpiaRegs.SPISTS.bit.BUFFULL_FLAG = 0;
    SpiaRegs.SPISTS.bit.INT_FLAG = 0;
    // Set reset low before configuration changes
    // Clock polarity (0 == rising, 1 == falling)
    // 16-bit character
    // Enable loop-back
    SpiaRegs.SPICCR.bit.SPISWRESET = 0;
    SpiaRegs.SPICCR.bit.CLKPOLARITY = 0;
    SpiaRegs.SPICCR.bit.SPICHAR = (8-1);
    SpiaRegs.SPICCR.bit.SPILBK = 0;

    // Enable master (0 == slave, 1 == master)
    // Enable transmission (Talk)
    // Clock phase (0 == normal, 1 == delayed)
    // SPI interrupts are disabled
    SpiaRegs.SPICTL.bit.MASTER_SLAVE = 1;
    SpiaRegs.SPICTL.bit.TALK = 1;
    SpiaRegs.SPICTL.bit.CLK_PHASE = 0;
    SpiaRegs.SPICTL.bit.SPIINTENA = 0;

    // Set the baud rate
    SpiaRegs.SPIBRR.bit.SPI_BIT_RATE = SPI_BRR;

    // Set FREE bit
    // Halting on a breakpoint will not halt the SPI
    SpiaRegs.SPIPRI.bit.FREE = 1;

    // Release the SPI from reset
    SpiaRegs.SPICCR.bit.SPISWRESET = 1;
}

//
// InitSpiGpio - This function initializes GPIO pins to function as SPI pins.
//               Each GPIO pin can be configured as a GPIO pin or up to 3
//               different peripheral functional pins. By default all pins come
//               up as GPIO inputs after reset.
//
//               Caution:
//               For each SPI peripheral
//               Only one GPIO pin should be enabled for SPISOMO operation.
//               Only one GPIO pin should be enabled for SPISOMI operation.
//               Only one GPIO pin should be enabled for SPICLK  operation.
//               Only one GPIO pin should be enabled for SPISTE  operation.
//               Comment out other unwanted lines.
//
void InitSpiGpio()
{
   InitSpiaGpio();
}

//
// InitSpiaGpio - Initialize SPIA GPIOs
//
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.GPIO5 = 0;   // Enable pull-up on GPIO5 (SPISIMOA)
    GpioCtrlRegs.GPAPUD.bit.GPIO17 = 0;  // Enable pull-up on GPIO17 (SPISOMIA)
//  GpioCtrlRegs.GPAPUD.bit.GPIO3 = 0;   // Enable pull-up on GPIO3 (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.GPAQSEL1.bit.GPIO5 = 3;  // Asynch input GPIO5 (SPISIMOA)
    GpioCtrlRegs.GPAQSEL2.bit.GPIO17 = 3; // Asynch input GPIO17 (SPISOMIA)
//  GpioCtrlRegs.GPAQSEL1.bit.GPIO3 = 3;  // Asynch input GPIO3 (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.GPAMUX1.bit.GPIO5 = 2;  // Configure GPIO5 as SPISIMOA
    GpioCtrlRegs.GPAMUX2.bit.GPIO17 = 1; // Configure GPIO17 as SPISOMIA
//  GpioCtrlRegs.GPAMUX1.bit.GPIO3 = 2;  // Configure GPIO3 as SPISOMIA
    GpioCtrlRegs.GPAMUX2.bit.GPIO18 = 1; // Configure GPIO18 as SPICLKA
    GpioCtrlRegs.GPAMUX2.bit.GPIO19 = 1; // Configure GPIO19 as SPISTEA

    EDIS;
}

//
// End of file
//

and I just turned off the loopback mode and short-circuited MOSI and MISO for testing. The result is that I can send and receive data. The results are as follows:

Does this result indicate that there may be a problem with the slave hardware?

Best Regards,

Ben

Hi Ben,

Apologies I misread where you call the init, your SPI configurations seem to follow the standard protocol. 

To clarify your TRM reference question: The spi_ex1_loopback.c is a different example than the one you are referring to (the other example is driverlib-based whereas the one you refer to is bitfield-based). This other example is located in the driverlib folder: {C2000Ware}\driverlib\f2837xd\examples\cpu1\spi whereas more bitfield-based examples are located in the device support folder at {C2000Ware}\device_support\f2837xd\examples\cpu1.

I also wanted to ask a few questions to clarify what your goals are for your application so I can better understand and help- are you only trying use loopback for internal validation, or are you trying to communicate with some external device? With SPI loopback mode enabled, SIMO/SOMI lines are connected internally with no external connections, which is used for module self-tests and used in internal loopback examples. What slave hardware are you referring to?

Best Regards,

Allison

Hi Allison,

My slave is an encryption chip. The relevant wiring is currently checked correctly, and I personally feel that if the SPIDAT register is always 0, it may be a problem on the 28377d side, because the process of transmitting from spitxbuf to spidat  should be a process that occurs internally within the 28377d chip.

Best Regards,

Ben

Hi Allison,

By the way, I think I might want to explain to you some errors that we have eliminated so far. There may be some problems with the previous baud rate setting. The SPI clock frequency should be set to 1MHZ and below, but after we adopt the correct baud rate setting The communication problem was not resolved. Here we tried two values ​​​​1E6 and 0.5E6 respectively, corresponding to the SPI clock frequency of the standard 1MHZ and the lower 0.5MHZ, but neither solved the problem. The changes are as shown in the figure:

In addition, we also checked the settings of CPOL and CPHA. Both are 0, which is no problem. As shown below:

The current phenomenon is: SPIDAT is always 0 after the slave chip is connected and when the slave chip is not connected. Only when the loopback self-tests, or the MOSI and MISO of the dsp are short-circuited, can the data in SPITXBUF be sent to SPIDAT normally and the same data can be received.

Looking forward to the reply.

Best Regards,

Ben

Hi Ben,

Thanks for the reply and information on your findings so far. So to reiterate (please correct if I am wrong in my understanding):

• When you turn off internal loopback mode and externally connect the MISO/MOSI lines together, you are able to see communication as expected
• When you turn off internal loopback mode and used the 4 SPI lines to the slave (no wire directly connecting/shorting MISO to MOSI) to try to transmit data to the encryption chip (and receive data from the chip) you see that the SPITXBUF has data and SPIDAT is always 0

If you are seeing proper data sent when doing an external loopback (MISO/MOSI shorted), that tells me that your code is running ok and you have proper SPI communication successfully. In master mode, when you write data to TXBUF, the data is shifted to SPIDAT and immediately sent out on the MOSI line, so you will not see transmitted data in SPIDAT. Instead, SPIDAT would show the received data shifted in from the MISO line. So if the slave device is sending zeros, that is what you would be seeing in SPIDAT.

So to help debug, please use an oscilloscope/analyzer to view the activity on the 4 SPI lines. Specifically, we need to check that the SPICLK shows pulses and check the MISO line to see if the slave device is sending data or sending zeros to the master. 

Best Regards,

Allison

Hi Allison,

I checked SPICLK, it seems that no matter what frequency of SPICLK is given here, there will be no signal, the waveform is always a straight line。

What could be the reason for this? Is it because the SPI clock signal setting in the program is not in place?

 Another question, do we need  a delay before receive and transmit in the spi communication of dsp 28377d? Will it cause the loss of data?

Best Regards,

Ben

Hi Ben,

Thanks for the information. Here are a few follow-up questions and my responses:

1. Is that oscilloscope image above from when you are trying to communicate with the external device with loopback mode off?
2. When trying to communicate with the slave device, can you check what your LSPCLK and BRR are? Assuming LSPCLK is 50MHz and your target SPI baud rate is 1MHz, SPI_BRR should be 49.
3. Can you confirm that the below is true for you:

Allison Nguyen said:

• When you turn off internal loopback mode and externally connect the MISO/MOSI lines together, you are able to see communication as expected
• When you turn off internal loopback mode and used the 4 SPI lines to the slave (no wire directly connecting/shorting MISO to MOSI) to try to transmit data to the encryption chip (and receive data from the chip) you see that the SPITXBUF has data and SPIDAT is always 0

Can you please use an oscilloscope/analyzer to view the 4 SPI lines when using external loopback (the first bullet point case above) and ensure the waveforms look correct. The SPIA from InitSpiaGpio() uses GPIO16, GPIO17, GPIO18, GPIO19, so these should be the pins you are looking at. 

Ben Qin said:

 Another question, do we need  a delay before receive and transmit in the spi communication of dsp 28377d? Will it cause the loss of data?

You don't necessarily need delay, but for example if you are using FIFO mode, it is always best to check that there is space in the transmit FIFO before writing to TXBUF and check that there is an expected amount of complete/valid data in the receive FIFO before reading from RXBUF. This can be done with a simple "while" loop that checks the FIFO levels (TXFFST and RXFFST bits) before you write/read. 

Best Regards,

Allison

Hi Allison,

 I did some debugging this morning and was finally able to communicate with spi. However, according to the return value of the slave, the data received by the slave is wrong. The strange thing is that as I said before, it is spontaneous or self-receiving. When MOSI and MISO are short-circuited, the data are all correct. I will go to the lab to see the waveforms and try it out later.

In addition, the previous problem may be because spi is a full-duplex communication protocol. To receive, you must send first, and to send, you will also receive. So I modified the program and merged sending and receiving. The program changes are as follows:

I don’t know if this can perfectly solve the problem, or will it bring me new problems mentioned above?

Best Regards,

Ben

Hi Ben,

Glad you were able to establish communication. What is it that you changed in the program to fix the issue? If the data is received incorrectly, you can also check the MOSI waveforms to clarify if the data sent by the master looks correct. Also, SPI is indeed full-duplex, meaning when the master sends a byte of data by writing to TXBUF, the master also receives a byte of data in RXBUF. Let me know if you have further questions/need clarification of this point.

The SPIA_Send_Receivebyte() looks correct, though it would be best to check the TX FIFO status to make sure there is space to write to it before writing to TXBUF. It would be helpful if you could explain what exactly you are trying to accomplish from a system-level and specifically in SPI_RXBuff() and SPI_TXBuff() functions you showed above as well. And is there a reason you have the delay(10) in them?

Best Regards,

Allison