SPI (or SCB) block pins and logic

[NiLe_4796031]

I'm trying to connect my SPI master SS pin through some simple FPGA logic (a couple AND gates, a NOT gate, a DFF and a TFF -- see attachment). I'm getting these errors from PSoC Creator:

> Pin guidance unavailable: Invalid connection for output "\SPI_1:SCB\:spi_select_0" connected to "Net_45:main_0".

> Pin guidance unavailable: Invalid connection for output "\SPI_1:SCB\:spi_select_0" connected to "cy_tff_1D:main_0".

> Pin guidance unavailable: Invalid connection for output "\SPI_1:SCB\:spi_select_0" connected to "cydff_1:main_0".

> Invalid connection for output "\SPI_1:SCB\:spi_select_0" connected to "Net_45:main_0". The listed output from the component can only be connected to a pin or Smart IO. Update your design and rebuild.

> Invalid connection for output "\SPI_1:SCB\:spi_select_0" connected to "cy_tff_1D:main_0". The listed output from the component can only be connected to a pin or Smart IO. Update your design and rebuild.

> Invalid connection for output "\SPI_1:SCB\:spi_select_0" connected to "cydff_1:main_0". The listed output from the component can only be connected to a pin or Smart IO. Update your design and rebuild.

I know from the SCB datasheet says:

> "By default, the SPI pins are buried inside Component [...] because they use dedicated connections and are not routable as general purpose signals."

I believe this has to do with the errors I'm receiving. Is there some other way to achieve what I'm trying to build here without involving the CPU? Can I virtually connect it to another pin which has the logic? Worst case, I could connect two pins through the board design, but is there any way that could work on the same clock cycle?

[RodolfoGL]

You can't connect any of the SCB SPI pins to the UDBs.

It seems you want the SS line to generate a pulse, instead of active low. The SPI component has a "Sub mode" option that can slightly change the way the SS line works. See if "TI (Start Coincides/Precedes)" work for you.

If not, another way to solve this is to use the Smart I/O to generate such a logic. But you are restrict to use the SPI from Port 8 or 9. 

[NiLe_4796031]

I want the SS line to stay low for 2 contiguous samples, and I may have gotten the logic wrong. It should be a) DFF stores our SS_prev b) TFF stores the even-odd count c) compare SS and SS_prev to detect rising edges d) when we see a rising edge, "increment" the TFF e) AND to only allow output-pin SS to go high when our TFF count is #1 (after even packets) and SS is high. This is an attempt to get 32-bit SPI by using two packets of 16-bit SPI and removing the pulse assertion of SS in the middle of the 32.

> If not, another way to solve this is to use the Smart I/O to generate such a logic. But you are restrict to use the SPI from Port 8 or 9. 

Could you expound on this a bit? Can I connect the SPI port to Smart I/O?

[RodolfoGL]

Yes, you can connect the SPI port to Smart I/O.

We have two ModusToolbox code examples that use SPI + Smart I/O to do something totally different.

https://github.com/Infineon/mtb-example-psoc6-smartio-sgpio-target

https://github.com/Infineon/mtb-example-psoc6-smartio-i2s

These examples wouldn't help you much for your case, but it can give you some perspective what it is possible combining SPI + Smart I/O. In both cases, the SS pin was manipulated to work differently.

In PSoC Creator, you can refer to the CE209976 code example.

Another thing I want to point out. Based on the description of your last post, it seems you could implement what you want without any changes in the hardware. You could generate a 32-bit SPI packet by writing twice to the SPI TX buffer. You just need to make sure you write the second word before the first finishes and the component has the "Deassert SS Between Data Elements" unchecked.

[NiLe_4796031]

---

@RodolfoGL wrote:

Yes, you can connect the SPI port to Smart I/O.

We have two ModusToolbox code examples that use SPI + Smart I/O to do something totally different.

https://github.com/Infineon/mtb-example-psoc6-smartio-sgpio-target

https://github.com/Infineon/mtb-example-psoc6-smartio-i2s

These examples wouldn't help you much for your case, but it can give you some perspective what it is possible combining SPI + Smart I/O. In both cases, the SS pin was manipulated to work differently.

In PSoC Creator, you can refer to the CE209976 code example.

Another thing I want to point out. Based on the description of your last post, it seems you could implement what you want without any changes in the hardware. You could generate a 32-bit SPI packet by writing twice to the SPI TX buffer. You just need to make sure you write the second word before the first finishes and the component has the "Deassert SS Between Data Elements" unchecked.

---

Thanks! Unfortunately the SPI slave device requires SS to be asserted on every 32-bits exactly. What I've currently got is a system where I run the SS pin by software (Cy_GPIO_Write) and while this works in isolation, it won't work for our final product. We need to communicate a minimum of 6 x 32-bit SPI commands every 10 kHz, where the timing on the 10 kHz must be exactly precise (never early or late). For that I use a clock + timer and an interrupt handler at maximum priority, but we also need to send the data over BLE at the max rate the BLE is capable of. For that we run a while (1) { Cy_BLE_GATTS_Notification } whenever the BLE stack says it's not busy. If I add so little as a single memcpy of 512 bytes into that hot loop -- to simulate reading data that was written to by the interrupt handler -- then it slows down BLE to the point where the whole product does not achieve enough bandwidth.

My current idea is to remove the 10 kHz interrupt, replacing it with a DMA channel. However, this requires a hardware solution to the SS pin, such that it does update every 32 but not every 16.

I think I've made something that might work using Smart I/O (attached, untested), but am I correct in understanding that I need to apply a soldering iron to my Pioneer kit board to move a resistor in order to route the P8[3/F7 to I/O instead of CapSense??

[NiLe_4796031]

---

@RodolfoGL wrote:

Yes, you can connect the SPI port to Smart I/O.

We have two ModusToolbox code examples that use SPI + Smart I/O to do something totally different.

https://github.com/Infineon/mtb-example-psoc6-smartio-sgpio-target

https://github.com/Infineon/mtb-example-psoc6-smartio-i2s

These examples wouldn't help you much for your case, but it can give you some perspective what it is possible combining SPI + Smart I/O. In both cases, the SS pin was manipulated to work differently.

In PSoC Creator, you can refer to the CE209976 code example.

Another thing I want to point out. Based on the description of your last post, it seems you could implement what you want without any changes in the hardware. You could generate a 32-bit SPI packet by writing twice to the SPI TX buffer. You just need to make sure you write the second word before the first finishes and the component has the "Deassert SS Between Data Elements" unchecked.

---

Thanks! Unfortunately the SPI slave device requires SS to be asserted on every 32-bits exactly. What I've currently got is a system where I run the SS pin by software (Cy_GPIO_Write) and while this works in isolation, it won't work for our final product. We need to communicate a minimum of 6 x 32-bit SPI commands every 10 kHz, where the timing on the 10 kHz must be exactly precise (never early or late). For that I use a clock + timer and an interrupt handler at maximum priority, but we also need to send the data over BLE at the max rate the BLE is capable of. For that we run a while (1) { Cy_BLE_GATTS_Notification } whenever the BLE stack says it's not busy. If I add so little as a single memcpy of 512 bytes into that hot loop -- to simulate reading data that was written to by the interrupt handler -- then it slows down BLE to the point where the whole product does not achieve enough bandwidth.

My current idea is to remove the 10 kHz interrupt, replacing it with a DMA channel. However, this requires a hardware solution to the SS pin, such that it does update every 32 but not every 16.

[RodolfoGL]

Yes, you need to do some changes in the kit's board. The CapSense pads will add a lot of capacitance to the bus, and it seems you want to run the SPI at 25 MHz, so better isolate the line. If you check the CY8CKIT-062-BLE schematics, search for the "CapSense Multiplexed pins" to know which resistors you need to add/remove.

Still, I don't think you need to use the Smart I/O. You can use the DMA to do the 6 32-bit transfers. 

For example, your X loop can be setup for 2 transfers and your Y loop for 6 transfers. The catch here is that you might need to add some additional delay every 2 transfers, so the SPI Master has time to de-assert the SS line.

If the above configuration doesn't work, you could create 6 descriptors or 12 descriptors. You might need to add some dummy transfers to slow down the DMA.

Or you could create some hardware circuit to trigger the DMA in hardware for every 2 transfers and control the delay between them.

[NiLe_4796031]

I don't think the SPI datasheet explains when it does deassert SS when "deassert SS between data elements" option is unchecked. As long as it deasserts when TX FIFO is empty, then this should work.

I've been unable to get a simple example of DMA+SPI going. I was cribbing off of CE221120 only to discover that this example doesn't seem to work on my PSoC6 BLE pioneer board either (the LED doesn't light, my logic analyzer shows that the master sends two packets then stops). I'm not sure how to proceed debugging, I assume this code example works for you?

[RodolfoGL]

I'm attaching a simple project implementing what I proposed.

I don't have a BLE kit, but you can switch the project to BLE and it should work. Note that I drop the Clock_Slow frequency (25 MHz) to slow down the DMA, otherwise the DMA is fast enough to fill up the SPI TX FIFO and you wouldn't see the SS line de-asserting.

Here is a screenshot of what I captured with a logic analyzer:

Let me know if this works for you.

[NiLe_4796031]

Thank you, the code is much simpler than I got from the other code example.

However, it doesn't seem to exactly work right. According to my logic analyzer, I'm getting oddly spaced blocks in the clock signal. I'm confident this isn't a quirk of my logic analyzer, they do occur every 6-long block sent from your code but if I reprogram with my original code (that does not use deassert SS and manually controls the SS pin with the CPU) then the clock never shows these gaps.

My board is a CY8C6347BZI-BLD53.

[RodolfoGL · Accepted solution]

I didn't observe exactly this problem. But I was able to observe some corruption on the data. It seems the DMA is still too fast.

I tweaked a bit the clock and configure the SPI to assert the TX_DMA only when the FIFO is empty. I also added some debug signals. See if this works now.

[NiLe_4796031]

This works for me. Thank you so much!!