# SPI clock synchronization issue and inconsistency with data output

I have got the spi active and have tested the working of SCLK, MOSI and CS w.r.t the program with TI CC3200 LP Rev 3.2. While testing, I noticed some of the following issues such as:

1. The data bits clocked out from MOSI are not matching with the actual data byte being sent

2. Sometimes, the data out is clocked out even before the start of the clock signal and I was wondering how can this be possible.

SPI configured for Bit Rate of : 100 KHz

SPI Sub Mode : 0 i.e. If I have understood it right -- The data is sampled on the rising edge of the clock signal and the data bit is clocked out during the falling edge of clock signal

SPI Mode: MASTER

The FIG(1) below shows the DSO output that addresses the issue (1) relevant data mismatch. The Blue line is data line and Yellow one is clock signal.

In FIG (1), I have transmitted a character "A" i.e 0x0A. The expected data output bits supposed to be (MSB) 0000 1010 (LSB) in binary w.r.t the eight clock cycles shown above. However, form my perception of the signals, I am getting some other data at the output and not 0x0A. Please let me know if the data out what I am getting is actually wrong or I have interpreted the signals in a wrong way. This same issue applies to FIG (2) below as well when I transmit a character "B" i.e. 0x0B.

Just for more information, I am also attaching an image below with FIG(3), which show the transmission of 5 bytes i.e. "ABCDE".

The FIG(4) below shows the DSO output that addresses the issue (2) relevant data being generated even before the start of the clock signal. The Blue line is data line and Yellow one is clock signal.

In FIG (4), I have transmitted a character "F" i.e 0x0F. The expected data output bits supposed to be (MSB) 0000 1111 (LSB) in binary w.r.t the eight clock cycles shown above. Here too, I am getting some other data as well as , it can be seen that the data out is clocked out before the clock signal and there is not sync between the clock and the data.

Below is the software/program I used while performing these tests in master mode, which is a slight modification of the actual spi_demo example in the SDK :

  #define MASTER_MODE      1

#define SPI_IF_BIT_RATE  100000
#define TR_BUFF_SIZE     100

//Default start strings
#define MASTER_MSG       "ABCDEFGHIJ"
#define SLAVE_MSG        ""

void MasterMain()
{

int i;
int bytecount = 1;
unsigned long ulUserData;
unsigned long ulDummy;

memcpy(g_ucTxBuff,MASTER_MSG,sizeof(MASTER_MSG));

ucTxBuffNdx = 0;
ucRxBuffNdx = 0;

MAP_SPIReset(GSPI_BASE);

MAP_SPIConfigSetExpClk(GSPI_BASE,MAP_PRCMPeripheralClockGet(PRCM_GSPI),
SPI_IF_BIT_RATE,SPI_MODE_MASTER,SPI_SUB_MODE_0,
(SPI_SW_CTRL_CS |
SPI_4PIN_MODE |
SPI_TURBO_OFF |
SPI_CS_ACTIVELOW |
SPI_WL_8));

MAP_SPIEnable(GSPI_BASE);

Message("Enabled SPI Interface in Master Mode\n\r");
Report("Press any key to transmit data....");

while(1)
{
ulUserData = MAP_UARTCharGet(UARTA0_BASE);

MAP_SPITransfer(GSPI_BASE,g_ucTxBuff,0,bytecount,
SPI_CS_ENABLE|SPI_CS_DISABLE);

Report("\r\n\nSending:");
for(i = 0; i < size; i++)
{
Report("%c", g_ucTxBuff[i]);
}
Report(":");

for(i = 0; i < size; i++)
{
Report("%02X, ", g_ucRxBuff[i]);
}
Report(":\r\n");

}
}


Any help, information or advise on changes to be made regarding this would be appreciated. Thanks in advance.

Regards

~VD

• Your scope shots came from a unit with an LCD display. I would refrain calling such device a CRO. – Michael Karas Jul 30 '16 at 9:56

When you send an "A" character you are not getting a value of 0x0A. Instead you are getting the binary value that corresponds to the ASCII encoding for the "A" character. The values below show the ASCII encodings for some characters:

"A" = 0x41 = 0b0100_0001
"B" = 0x42 = 0b0100_0010
"C" = 0x43 = 0b0100_0011
"D" = 0x44 = 0b0100_0100
"E" = 0x45 = 0b0100_0101
"F" = 0x46 = 0b0100_0110


If you want to send an actual value of a given binary such as 0b0000_1010 the give that value to the output routine instead. Writing the number in hexadecimal would be 0x0A.

NOTE: I have used an underscore in the binary numbers to separate the separate 4-bit nibbles to make it more readable. This would not be accepted by most compiler tools.

In your pictures the SPI mode that you have selected outputs the first data bit a half a clock time before the first emitted clock. You may want to experiment with choosing the various modes available and seeing what they look like on the scope. This will help you to better understand the positioning of the data bits with respect to the clock.

• I have tried sending 0x0F by doing this as well MAP_SPITransfer(GSPI_BASE,(unsigned char*)0x0F,0,bytecount,SPI_CS_ENABLE|SPI_CS_DISABLE);. – PsychedGuy Jul 30 '16 at 9:45
• Directly sending a hexadecimal i.e. 0x0F, as you can see in the image attached that the binary output does not correspond to 0x0F – PsychedGuy Jul 30 '16 at 9:46
• Your right about the characters being transmitted in ascii format and thanks for pointing that out. It clears some major doubts. – PsychedGuy Jul 30 '16 at 9:53
• Well - your posted code shows sending ASCII codes and corresponds exactly to what I posted in my answer for your Figures 1, 2 and 3. For your Figure 4 it looks like you achieved sending out a 0x1110_0111. – Michael Karas Jul 30 '16 at 9:53
• Ok, but any idea, In Fig 4, how come the data being clocked out before even the the clock pulses being generated? – PsychedGuy Jul 30 '16 at 10:00