Problems with SPI

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Hi everyone,

I am working on a big project where I will have 9 PSoC3 devices working together.

A short description of the project:

   

8 PSoC3 devices to "read", amplify, filter and store locally 8 analog sensors.
1 PSoC3 device to rule them all! This will be the master SPI and the rest will be slaves.

The master has to periodically acquire the data gathered from the 8 slaves and store them on an SD Card. Hopefully the SPI has to transmit with a bit rate of 8 MHz.

   

The setup:

   

To test the SPI I am using two CY8CKIT-001 and trying to transmit 4 bytes both ways. I also read somewhere that SPI communication is not very good for long wires so to make it as short as possible I am connecting the ports of the dev kit directly like this:

   

   

 
I have also connected the grounds of the two dev kits together.

   

I have tried several different setups with DMA transfer and with ISR but nothing worked. So, now I am trying to make it as simple as possible. Just send and receive 4 bytes on each side. I don't think it gets any simpler than that. I have attatched the code on a txt file.

Both SPIs are configured in Mode3 (11), with MSB first @ 1kHz (lowest possible for the test. In the final project I want it to run around 8MHz).
I am reseting the Slave first and 2-3 seconds later the Master.
So in theory it should work like this:

1. The slave is reset and initialized
2. Slave places the 1st byte in the transmit buffer
3. Slave waits until a byte is received
4. Master is reset and initialized
5. Master sends 1 byte
5. Master waits until the byte is transmitted
6. Slave and master both read the received bytes
7. Master waits for 50ms (I have tried higher values also with same results)
8. Slave prints the byte on LCD and places the next byte to be transmitted on the TX buffer
9. Slave waits until a byte is received
10. Master sends next byte
and so on... until 4 bytes have been exchanged.

It should work properly, right? Well it doesn't.
On the Slave LCD I get from 2 to 4 bytes printed (usually 2) with only the first byte being always correct ("a").
On the Master I get 4 bytes usually with 1 random byte being correct but never all of them.

It's driving me crazy! I am 100% I am missing sth but I can't find out what.

I'm buying beer to whoever helps me with this  😛

   

 

   

 Bonus question:

   

Is it possible to use two master SPI components on the same design? So that I can talk to 2 slaves on the same time.

0 Likes
12 Replies
Anonymous
Not applicable

You have used PIM_STS_TX_FIFO_EMPTY

0 Likes
Anonymous
Not applicable

You have used SPIM_STS_TX_FIFO_EMPTY to wait for transmission complete.  FIFO empty does not mean that the character in the shift register has been shifted completed.  That is why you are seeing junk characters.

   

Instead use SPIM_STS_TX_BYTE_COMPLETE flag and see if this solves the problem.  With the BYTE_COMPLETE flag, you dont need the 50mS delay too.

0 Likes
Anonymous
Not applicable

Thank you for the reply.

   

The reason I used SPIM_STS_TX_FIFO_EMPTY is because that is what it is used in the "SPI Master and Slave in Loopback" example.

   

I will try it tomorrow and come back with the results.

0 Likes
Anonymous
Not applicable

Hi,

   

Today I treid the above mentioned solution but it didn't seem to solve my problem. But I hooked up an oscilloscope to check what's going on and noticed that very often the byte sent from the slave was shifted to the right.

   

So instead of sending:                                                             11110000
It was sending:                                                                                                                                01111000
And that is why the Master returned an error.

Now I don't know why this is happening, since I have both devices configured in the same mode. I also have unselected the "input sinchronized" on all input pins as stated on the SPIM and SPIS datasheets.

Any ideas?
 

0 Likes
Anonymous
Not applicable

I'm sorry I forgot to mention that I was suggested to try a more structured code with some sort of communication protocol. So that's what I did. Although still very simple.

   

Now the Master sends a command (0x01) and the slave has to reply according to the command.

   

So if the Slave receives 0x01 it sends back 0x30 else it sends 0xFF. Also the slave always sends a "start byte" and an "end byte". So the reply is in the following form:                                                      

   
    0x0F;              //Byte indicating start of transmission   
   
    response;        //0x30 or 0xFF   
   
    0xF0;              //Byte indicating the end of transmission   
   
        
   
    Now the master doesn't have a way of knowing when the slave has data ready to send. So when it sends the command, it continiously reads bytes until it reads "0x0F" then the next byte should be the actual response and  the following byte should be "0xF0". If it's not then it returns an UNEPECTED_ERROR.   
   
        
   
    I have uploaded the latest project.   
0 Likes
MR_41
Employee
Employee
First like received

Let me try to get some help on this.

Best Regards,
Ganesh
PSoC Hacker

0 Likes
Anonymous
Not applicable

Please do. I am litteraly dreaming of the SPI. It's not leaving my head even in my sleep.

   

It's a nightmare!!!

0 Likes
Anonymous
Not applicable

I have some people looking into this problem.  Just for clarification, have you by chance created a tech support case with Cypress on this issue?

   

Also, is your problem with the SPI with DMA project or SPI Master and Slave Loop Back project?

0 Likes
Anonymous
Not applicable

Did this ever get closed out?

   

I have similar issues with the SPI master...talking to a memory device in mode 3 the TX data goes out OK, but the RX data is bit-shifted by 1 clock phase.

   

Have had to bit-bang the SPI and ignore the hardware module until it is fixed.

   

BTW, the SS line is fairly useless, since it is used as SOF/EOF on many devices, so most of the time you do not want to drive SS low every 8 bits, only at the beginning and end of  variable length packets.

0 Likes
Rolf_Nooteboom
Level 5
Level 5
10 sign-ins 5 solutions authored First solution authored

Nick,

   

Have you unchecked the 'synchronized input' mode for the MISO pin?

   

Regards,

   

Rolf

0 Likes
Anonymous
Not applicable

Rolf, I don't remember.  Did that part of the code about a month ago, and remember I tried most things at the time.

   

                                                  

   

When I was digging around in the verilog template I came across these comments .     

    

   

     

            

   

* SPIM_POL = 0, SPIM_CPHA = 0   // Rising edge mode; Data latched at rising edge; set at falling edge      

   

* SPIM_POL = 1, SPIM_CPHA = 0   // Falling edge mode; Data latched at rising edge; set at falling edge      

   

* SPIM_POL = 0, SPIM_CPHA = 1   // Rising edge mode; Data latched at falling edge; set at rising edge      

   

* SPIM_POL = 1, SPIM_CPHA = 1   // Falling edge mode; Data latched at falling edge; set at rising edge      

    

   

     

            

   

Assuming the SPI modes are represented by the POL and C_PHA bits (not necessarily true), the Configuration diagrams in PSoC creator show this assignment instead     

    

   

     

            

   

// Mode 0,[0,0]                 Idle clock is LOW, Data set on falling edge, latched on rising edge     

   

// Mode 1, [1,0]                Idle clock is HIGH, Data set on set on Rising edge, latched on falling edge     

   

// Mode 2, [0,1]                Idle clock is LOW, Data set on Rising Edge, latched on falling edge     

   

// Mode 3, [1,1]                Idle clock is HIGH, Data set on falling edge, latched on rising edge     

    

   

     

            

   

Comparing this with the template, the verilog comment is very muddled and Mode 3 is definitely wrong. (But as its only comments, it is perhaps not important.)

   

 

   

Spoke to local FAE at the time, and he said that the SPI master didn't work in mode 3 when he used the example project.  I thought it might have been fixed in Beta5.    

  Will try it out again later aned let you know.   
0 Likes
Anonymous
Not applicable

Update,

   

inserted SPI master v2.0 into my project and got

   

WARNING: C:\CYPRESS\PSOC PROJECTS\HAWKRECOVER\HAWKALPHA\HAWKALPHA.CYDSN\GENERATED_SOURCE\PSOC3\SPIM_1.C:153: 'CyEnterCriticalSection': missing function-prototype
WARNING: C:\CYPRESS\PSOC PROJECTS\HAWKRECOVER\HAWKALPHA\HAWKALPHA.CYDSN\GENERATED_SOURCE\PSOC3\SPIM_1.C:159: 'CyExitCriticalSection': missing function-prototype
ERROR: C:\CYPRESS\PSOC PROJECTS\HAWKRECOVER\HAWKALPHA\HAWKALPHA.CYDSN\GENERATED_SOURCE\PSOC3\SPIM_1.C:159: 'CyExitCriticalSection': requires ANSI-style prototype
The command 'c51.exe' failed with exit code '2'.

   

The older version (v1.20) didn't do that.

0 Likes