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:
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.
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.
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 -
- 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.
- 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
- 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 18.104.22.168 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
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 .
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
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)?
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.