3 Replies Latest reply on Mar 5, 2017 1:50 AM by JoMe_264151

    SPI Link Between 2 PSOC Chips




      I have a project where I am attempting to use SPI to transmit information between two PSOC devices. The device on the white circuit board is a CY8C4245PVI-482.


      The black circuit board is a CY8CKIT-059.


      The CY8CKIT-059 is a SPI master that requests information be sent from the CY8C4245PVI-482 slave upon a string command. The data request is terminated by a line break.


      As my code stands now, the data request arrives from the master intact and successfully executes the command parse routine in the firmware for the CY8C4245PVI-482 slave. The slave is then supposed to send a serial number back to the master. The characters "ABC\n" never arrive back reliably or intact to the master.


      I checked activity on the MISO and all the lines. It all looks OK, so I think there is some poor code practice I am using. Please assist me in resolving the data transfer issue I am having back from the slave to the master. I have the project files attached for both the slave and master. hopefully what I am doing hardware wise and my code is self-explanatory.



        • 1. Re: SPI Link Between 2 PSOC Chips

          Usually SPI works a bit unusual ;-)


          For every bit (byte) the SPI interface gets, one bit (byte) is returned immediately. When the very first byte is sent, the interface does not "know" yet what to answer, so usually a dummy byte is returned which should be skipped.
          SPI has no read command, so you must send dummy bytes to retrieve the information wanted. Check your program flow for this handling.


          A pitfall is the select line, which is automatically taken low before a byte is sent. When the buffer is empty it is taken high again. This can lead to interface errors when the byte sequence is not provided fast enough resulting in ss-line glitches.


          A yet hidden error lures in your interrupt handler: When you switch on the compiler optimization (as is done in release mode) your program will stop working. Since debugging does not work together with the optimization it is very difficult to get hands on the bug:


          As a general rule: Every global variable that gets changed in an interrupt handler must be declared as "volatile". In your case CommandEndFlag and BufferFilledFlag should be volatile uint8.





          • 2. Re: SPI Link Between 2 PSOC Chips

            Ultimately, I am trying to have the slave wait for a command string.


            In the slave code I have attached, every time a FIFO not full is detected, the command string from the master is read byte by byte. As it stands now, another string is returned character by character back to the master as dummy bytes are read in. My intent is not for information to be returned immediately but after the string command has been processed. I have been struggling with this.


            The huge caveat here is that string parsing and processing of the command takes a variable amount of CPU time on the part of the slave. How is it possible to have the master wait for the information to come back from the slave without showing up in random places in the buffer or garbled?


            Better yet, is there a more appropriate approach to SPI information retrieval from the software registers I will setup on the white PCB? If so, what would you recommend?

            • 3. Re: SPI Link Between 2 PSOC Chips

              Suggestion: Change your protocol which looks a bit more than a UART protocol (Messasges, newline at end).


              More common for SPI and !2C which are often used in external sensor devices is:


              Master sends a "register address" (a byte)  from which information should be retrieved by the slave, slave answers with an arbitrary byte.


              Master sends dummy bytes, slave answers with the wanted data.


              Tho ensure that there is time enough for the slave to set up its buffers on receipt of the initial address byte, the master can hold low the ss-line and wait some µs before sending out the dummy bytes.