7 Replies Latest reply on Jan 2, 2019 2:44 AM by MeenakshiR_71

    SPI Slave transfer done


      Hi everybody,

      has PSOC6 a way to get an interrupt when SCB SPI slave chip select is released or taken?


      In all examples, SPI slave has a fixed packet size and depend on it (RX FIFO sample count is used as transfer end condition). Our solution uses packets with variable length and we would like to use SPI chip select release as the event for RX FIFO read out.


      We tried to configure HW interrupt on the chip select pin and then change its HSIOM to SCB4_SPI_SELECT0. It generates interrupts on correct edges but sometimes interrupts are thrown without slave select state change (attached image).


      We would prefer a solution without UDB blocks.




        • 1. Re: SPI Slave transfer done

          Hi Ondrej,


          SCB_SPI has several interrupt source to use. Select 'External' for interrupt mode under Tab-Advanced of SPI, you could see its interrupt sources. Do you think it is possible to use these interrupt to transfer data in your project ?



          I didn't see a table to explain how these interrupts work, but I found a table in PSoC4 SCB SPI datasheet:


          Thanks, Ryan

          • 2. Re: SPI Slave transfer done

            Hi Ryan,

            none of SPI slave interrupt is thrown when a chip select pin is released. SPI master has SPI_DONE interrupt. The interrupt isn't accessible for the SPI slave mode.


            From TRM:

            SPI_DONE - SPI master transfer done event: all data frames in the transmit FIFO are sent, the transmit FIFO

            is empty (both TX FIFO and transmit shifter register are empty), and SPI select output pin is deselected.


            We would like to get the interrupt at the same time on SPI slave. The only way what I see is to use NOT_EMPTY interrupt and check if SPI transfer isn't running in the interrupt or use HW trigger on the chip select pin. The first is suboptimal and throws unnecessary lot interrupts 127 extra for a 128B long message. The other isn't working. It looks than pin cannot be shared between SCB SPI and HW interrupt.




            • 3. Re: SPI Slave transfer done

              Hello Ondrej,


              There is an interrupt available in the HW for your use case. However, this interrupt is supported ONLY EZSPI Mode (refer to PSoC 6 TRM) and only in SCB8 (deep sleep capable SCB in PSoC 6). In addition, the SCB driver does not expose the interrupt. In addition


              Some options at your disposal are -

              1. Use Cy_SCB_SPI_Transfer API along with a callback registered to the "CY_SCB_SPI_TRANSFER_CMPLT_EVENT" using Cy_SCB_SPI_RegisterCallback() API - this will call your callback when the transfer is complete but this may not relate to the slave select line - the transfer is defined as the number of bytes you want to transfer/receive in master or slave mode. So irrespective of the Slave select line, you will get the event whenever the transfer is complete.
              2. You can short the slave select pin to another pin externally and use the other pin for GPIO interrupt - not a good suggestion but should work for your need if you have a pin to spare and want this approach
              3. The SCB8 hardware does provide an option to generate an interrupt on Slave deselect after a write or read. However, this feature is available only in the EZSPI mode explained in our TRM. The master need to perform SPI actions as described in the section to make use of this interrupt. Our SCB driver does not expose or use it. So you will need to create your own driver for this use case. Refer to section of PSoC 6 TRM for details


              Let me know if this helps.


              Just a note, I have not tested the above suggestions but theoretically it should work let me know if you run into any issues



              Meenakshi Sundaram R

              • 4. Re: SPI Slave transfer done

                Hello Meenakshi,

                your uncorrected response gave me hope and updated version thrown it away.


                I understand it in the following way:

                Cypress SCB SPI slave doesn't support main SPI feature to know when a transaction starts and ends. It provides more something like UART than SPI slave. From the TRM: SCB SPI knows (SCBX_SPI_STATUS) about an ongoing transaction but doesn't propagate this information as the interrupt.


                How can I write SPI slave control application which has to process variable size transactions and recovers from unfinished transactions without slave select functionality?


                The only way for me is to use my hack to short chip select with a GPIO pin and set up extra HW interrupt .



                Ondrej Pilat

                • 5. Re: SPI Slave transfer done



                  This is exactly what the EZ-SPI mode is for the slave. Unfortunately, that function is limited to SCB8. I am afraid we do not have other options for this use case.


                  Alternative to shorting externally, Smart IO can be used to route the signal to two different paths and provide interrupt in one path.



                  Meenakshi Sundaram R

                  • 6. Re: SPI Slave transfer done


                    EZ-SPI mode is only partly what we need and as you written only usable with SCB8. It forces to send a special header to initialize EZ write/read and cannot be duplex (simultaneous message exchange). But still, thank you for your answers it helps me to understand more SCB SPI block.


                    I will look at the Smart I/O it at least removes the need to short pins externally.


                    Do I understand correctly that I will need to sacrifice a pin to use its interrupt HSIOM path?

                    Is not possible to use two HSIOM functionality on a pin (interrupt and slave select)?



                    Ondrej Pilat

                    • 7. Re: SPI Slave transfer done

                      Though obviously you cannot use the pin (which will be used to generate the interrupt) as an output pad, you might still be able to use it as an input (to Smart IO not HSIOM). At the end you will loose one HSIOM path for sure for routing both the Slave select and interrupt.