SPIS documentation not complete/incorrect

This forum is for the reporting and discussion of the PSoC documentation from Cypress (data sheet, TRM, user guide, etc).

Moderator: fsu

SPIS documentation not complete/incorrect

Postby Michael_Haub » Wed Aug 13, 2008 12:07 am


my app:

- PSoC doing CSD as its main task
- communication to master via SPIS
- SPIS switched of during CSD
(because sales man from cypress says irq from SPIS may corrupt CSD sample)
- SPIS multiple bytes in each cycle (e.g. 4 bytes)
- SPIS using software SS
- SPIS irq not enabled, polling
- PSoC slave is only sending, not receiving
- clocks from SPI master in cyclic packets (for the multiple bytes)
- PSoC-slave may start listening to SPIS in the middle of a clock packet
and may therefore not be able to send all its multiple bytes out, so using timeouts
for first byte, for other each byte, for all bytes. If timeout occures speeping to
synchronize on next clock packet.


1. documentation says:
"On the falling edge of the Slave Select signal, the data is transferred from the Tx Buffer register to the Shift register."

Finding: SPIS_EnableSS() and SPIS_DisableSS() have no influence on when TX data buffer is transfered to shift register.

2. documentation says:
"Data to be transmitted to the SPI Master is written to the Tx Buffer register. This clears the Tx Buffer Empty status bit."

Finding: On first SPIS_SetupTxData(...) data is automaticaly/imediatetly transfered to shift register and TX_BUFFER_EMPTY flag is therefore set.
On second SPIS_SetupTxData(...) data stays in TX data buffer and TX_BUFFER_EMPTY flag is reset.

3. documentation says:
"SPIS_bReadStatus ... Side Effects: The status bits are cleared after this function is called."

Finding: SPIS_bReadStatus() has no influence on status bit TX_BUFFER_EMPTY.

I have a problem with 1. How can i controll when TX data buffer is transfered to shift register, by my selfe?

What is the difference of TX_BUFFER_EMPTY and SPI_COMPLETE flag?
documentation says:
"Choosing the second option, "TxComplete," delays the interrupt until the last bit is shifted out of the Shift register."

But shift register is automatically loaded from TX data buffer when every bit of it has been shifted out (SPI_COMPLETE will be signaled) and then also SPI_COMPLETE flag would be set, or?

How could i tell the SPIS state machine that it should ignore the data automaticaly transfered from TX data buffer and go directly to the state when shift register is empty?

I think software has too low influence on the state machine.
State machine is not documentet correctly/enough.
A state diagram would be very helpfull.

Best regards
Posts: 4
Joined: Wed Jun 18, 2008 3:29 am

Postby todd » Wed Sep 03, 2008 4:57 pm

- PSoC-slave may start listening to SPIS in the middle of a clock packet

Is the master always clocking?
Cheese Wheel
Cheese Wheel
Posts: 135
Joined: Wed Dec 17, 2003 1:32 pm
Location: a desk!

Re: SPIS documentation not complete/incorrect

Postby fsu » Thu Sep 11, 2008 6:36 am

I will see if I can get some clarification and get back to you
--Steve Fouts
Technical Writer, Sr.
Cypress initials - FSU
Posts: 8
Joined: Mon Mar 24, 2008 7:54 am

Postby BitBangerB » Wed Dec 24, 2008 1:07 pm

I just lost about 2 days chasing down a problem similar to the original poster’s problem. Even if this were spelled out clearly in the documentation, it would still be incorrect behavior of the SPIS module.

I have discovered that in my SPIS ISR that after a write to the TX buffer, the TX buffer empty flag is not cleared (Michael’s point #2). At first I thought it had to do with SS* still being asserted by the master while the PSoC is servicing the interrupt. The state of SS* does not seem to matter.

It seems that no matter what, a write to the TX buffer results in an immediate transfer to the shift register. Presently my ISR always sets up the next TX byte as 0 every time. When it is time for me to actually send data to the master, the 0 is already stuck in the SPIS.

I end up with 0 going out on MISO during the next transaction. What I think is happening is when the write to the TX buffer takes place, it is immediately transferred to the shift register. This flies in the face of what is specified in the data sheet as Michael has indicated in point #1. The data written outside the ISR actually ends up coming out on the transmission after that.

For now anyway, I have found that stopping and starting the SPIS module when I am outside the ISR gets around the problem.

- B
User avatar
Cheese Wheel
Cheese Wheel
Posts: 126
Joined: Wed Apr 11, 2007 4:03 pm
Location: Arizona

Re: SPIS documentation not complete/incorrect

Postby bradsmokes » Thu May 06, 2010 10:13 pm

sounds good to me :D :D
Posts: 1
Joined: Thu May 06, 2010 9:59 pm

Return to “%s” PSoC Documentation Feedback

Who is online

Users browsing this forum: No registered users and 1 guest