SPI

Hello Han,

Of the four modes it uses SPI mode 2 for data communication.

There is sample programs available. You can refer to DLPC200 SPI spec http://www.ti.com/lit/ug/dlpu005a/dlpu005a.pdf and send/receive the command/response bytes as described in the document.

Regards,
Sanjeev

Thanks for your reply.

Uhmm.....  my question is.....

the SPI_ CLK samples the data sent from master at rising edge or falling edge.

In this DLPC200, when does it sample the data? (rising or falling)

this is related with master program.

And the other is about the sample programs.

I have the data sheet about your SPI specifications.

I'm confusing a little bit in programming for SPI communications.

Below is my SPI command sample program that I write in ATmega32.

// ---------------------------------------------------

// 1 byte transmission

// -------------------------------------------------

UINT8 SPIMasterWriteByte(UINT8 data){

while((SPI_PORT | (1<<ACK))) 
SPI_PORT &= ~(1<<SS); 

SPDR = data; // 1 byte data transmission.
while(!(SPSR & (1<<SPIF))); // waiting the transmission completed

SPI_PORT |= (1<<SS); // /SS is HIGH -> SPI is deactivated
return(SPDR); // return the data from SLAVE
}

UINT16 DisplayPatternManualStep() {

UINT8 CMD_BUFFER[] = {0x02,0xAA,0x00,0x00,0x02,0x00,0x01,0x00,0x00}; // Last byte is dummy
UINT8 CmdLen = sizeof(CMD_BUFFER)/sizeof(CMD_BUFFER[0]);

UINT8 i;
UINT16 CmdRtn;
UINT8* pCmdRtn;

pCmdRtn = (unsigned char*) &CmdRtn;

for(i=0; i<CmdLen; i++) {
    *pCmdRtn = SPIMasterWriteByte(*CMD_BUFFER++);
    *(pCmdRtn+1) = *pCmdRtn;
}
return CmdRtn; // If the CmdRtn's value is 0x0000,
                             // the command transmission is successful
}

In this program, the data is sampled at rising CLK edge and the checksum byte is not transmitted.

I just the check the last return command word.

Is this process OK with DPLC200 ?

Would you double check my SPI command sample program which is meet with DLPC200 spec?

Regards

YJ Han

Hi Han,

The DLPC200 samples data at the falling edge. Refer below waveform for more details.

Your code looks OK to me.

Regards,

Sanjeev

Hello Sanjeev,

For SPI communication protocol, I have one more question.

The SPI data transmission has two options.

One is to send out lsb first, the other is to send out msb first.

Which is right method for DLPC200?

Regards.

YJ Han.

Hi YJ Han,

The SPI master should send msb (most-significant-bit) first to the DLPC200.

Regards,

Sanjeev

Hi Sanjeev,

I  made a sample program for SPI communication testing.

The logic is simple

I just sent command packet in sequence - CMD1, CMD2, CMD3, CMD4, Len_LSB, Len_MSB, Data[0], Data[1], Checksum, Dummy_byte(0x00).

The Master system configuration is as belows.

   SPI mode2(falling edge sampling)

   lsb first transmission.

   SPI_CLK is 4MHz  

In your programmer's guide DLPU0005A (DLPC200 SPI Slave Interface Specification), there are two flow charts.

I followed the flow chart rule, Command Transmit Flowchart, 

But, it does not work.

Do I need some more logic or modifying it ?

As for the Reading command response, does it need to run the reading response ?

I need your help.

Regards.

YJ Han

Hello Han,

I suggest you to look into the the RX data on the SPI Master. According to DLPC200 SPI protocol every byte received at the DLPC200 is sent back to master in the next byte. So first check whether the RX data is matching to what Master is transmitting. If the received data at the Master is not matching then it will not work.

Few things you could try, try reducing the master clock like 1MHz see if it makes any difference. 

Regards,

Sanjeev

Hello Sanjeev,

I'm sorry for not to make any difference.

Anyway I have one question.

The question is how to interface Portability Layer DLL in SPI mode.

Doesn't it need ?

The DLPC200 is running in SL mode, parallel flash data source. 

Regards.

YJ Han

Hello Han,

Portability Layer DLL is not needed in SPI Mode.

The SPI slave on DLPC200 is provided to enabled external host controllers MCU or any other embedded processor to communicate it with as per the protocol and command specification provided in the DLPC200 SPI interface spec document.

To debug the problem first you much ensure what is written on the SPI Master is echoed back by the DLPC200. 

Then only you can proceed and use the SPI i/f of DLPC200 controller.

Regards,

Sanjeev

Hi Sanjeev,

Checked the SPI lines, there is no signals in SLAVE_SPI_MISO and SLAVE_SPI_ACK line.

My DLPC200 systems is DLP LightCommander Development kit and this system is connected with ATmega32 microcontroller.

The Master signals(MOSI, CS, CLK) are comming out normally.

Have you sample test programs in your side ?

I like to reference it.

Regards.

YJ Han.

YJ Han,

I put wrong information about the data sampling at the DLPC200, i have edited the same above now. The SPI master should send most-significant-bit first.

We tested with couple of options -

1. On the PC using USB-to-SPI converter board. 

2. BeagleBoard XM Rev C, configuring TI DM367 processor as SPI master and sending the commands to DLPC200.

Irrespective of the the bit-order lsb/msb first you must see there is activity on the SLAVE_SPI_MISO line. I suggest your SPI configuration timing are as per http://www.ti.com/lit/ds/symlink/dlpc200.pdf  under SPI Slave Interface section.

To debug i suggest following steps -

>> To start with set low clock rates like 500KHz or 1MHz

>> insert delay between each byte transmitted like 10uSec.

>> Send two bytes 0xAA 0xAA - check the data received back on the ATmega32 microcontroller receive register. It should 0xXX 0xAA (where first byte is don't care).

>> Send two bytes 0x55 0x55 - check the data received back on the ATmega32 microcontroller receive register. It should 0xXX 0x55 (where first byte is don't care) .

>> Once the above thing works then proceed with sending random data to make sure DLPC200 side is sampling it the data correctly. 

Regards,

Sanjeev

Hello, Sanjeev

Thanks to your comments, SPI interface begin to work.

But, it has still problems.

The current problem is as belows.

1. I should send SPI command two times for working well.

2. Some SPI commands stop to work, for example HorizontalFlip, VerticalFlip, SetLEDEnable, WriteImageOrderLut, etc

   After sending these commands, all commands do not work.

I set the SPI master as follows

  SPI CLK - 500KHz

 trying 10 - 100us delay between byte transmission

Is this a timing issue? or is there any other check point ?

I need your help.

Regards

YJ Han

Hello Sanjeev,

The answer is as follows.

#1. When you send first time are you reading the echo back properly?

  - Ans. I send command byte by byte in sequence.

             CMD1 , CMD2, CMD3, CMD4, Len_LSB, Len_MSB, DATA[0], DATA[1],........, CHECKSUM, dummy 0x00

             Every sending bytes, I read the echod back data in master and save whole echoed data in array CMD_RESP[ ].

             Is this the right way ?

#2. What happens when you increase the clk 1MHz, 2MHz,...

  - Ans. From 2MHz CLK, the SPI does not work

Regards.

YJ Han.

Dear YJ,

#1. Are you comparing the data received in CMD_RESP[] matches to CMD1 , CMD2, CMD3, CMD4, Len_LSB, Len_MSB, DATA[0], DATA[1],........, CHECKSUM, dummy 0x00?  You mentioned that first time it is not working, so I wanted to make sure it is receiving data correctly.  I also recommend you to probe the SPI bus signals and check if nothing wrong in it.

One more thing, after sending the command, are you also reading the response? Refer section 5.2 Reading Command Response http://www.ti.com/lit/ug/dlpu005a/dlpu005a.pdf

Regards,

Sanjeev

Hello Sanjeev,

As you mentioned, I checked the CMD_RESP[ ].

The first time master send command string, the slave(DLPC200) returns the command string back.

The 2nd time, the master reads the response from slave.

so, I sent 10 0x00 byte consecutively instead of original command string in 2nd time.( in case, DisplayPatternManualStep)

The result was fail. 

How many bytes should I send ? Should I send 0x00 value for reading command response?

.........

Would you explain me Reading Command Response in detail ?

I think the symptom some command don't work is related with Reading Command Response.

Regards

YJ Han.

Hello YJ,

From the DLPC200 SPI command spec

Any Write type command it will have 9-bytes as a response + 1 byte as the first byte returned is don't care. For example - DisplayPatternManualStep comes under such type command so you will have to send 10 dummy bytes in total.

If it is a Read or Query type command the DLPC200 command documentation shows number of bytes returned in the response, so add + 1. For example - GetDMDParkState (0x0013) command response returns 10 bytes response, so to read this response you are expected to send 10+1 = 11 dummy bytes.

While reading the response, we mentioned to send 0x00 as dummy byte, it is not compulsory, you can send anything, sending 0x00/0xFF is typically used to read the response.

You mentioned that the 'Result was fail' when you send DisplayPatternManualStep, how did you determine the result is failed? Can you show the response bytes? 

At the beginning while checking out the SPI interface b/w MCU and DLPC200 you can try simple commands like - 

Park/Unpark DMD,

Read different status via GetStatusxxx commands.

Regards,

Sanjeev

Hello Sanjeev,

Thanks to your help, SPI started working.

In WriteImageOrderLut command, I have another questions as below

 1. Data[2] is a bpp field and Data[3] & Data[4] are number of images, right ?

 2. In Data[3] & Data[4], which is LSB ?

 3. In case 3 image patterns in memory, Data[11], Data[12]......Data[504]  have 0x00 value, right ?

 4. In Checksum byte, the sum of all bytes after CMD4 exceed 0xFF.

     The next value of 0xFF is 0x00 ? or ......

Regards

YJ Han

Hello YJ,

#1. Yes.

#2. Data[3] is LSB

#3. For three images no need to include Data[1], Data[2],...Data[504]. After Data[10] directly Check-sum byte should come. Basically Data[3] & Data[4] tell the size of the image order LUT. If you said 3 images the DLPC200 expects you to send 6 bytes after Data[4] i.e., upto Data[10] then it should be Check-sum

#4. Yes when adding the bytes for check-sum the carry-over flag is ignored. After 0xFF it will be 0x00. 

Regards,

Sanjeev