How to control Chip Select Line Timing In ModusToolbox 1.1/ PDL?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
WeGa_288606
Level 4
Level 4
25 sign-ins 10 sign-ins 5 sign-ins

Hello,

I have a SCB configured in SPI mode on PSo62A series and I am wondering if the CS line assertion/deassertion timing can be controlled and if so how? I looked at the PDL API documentation but perhaps I am missing it ?

Thanks,

Wess

0 Likes
1 Solution

Hi Wess,

The reason the SPI transfer is using the same length for rx and tx buffers is based on the SPI protocol, as it requires the SPI clock and CS signal to be present when receiving data. In our SCBs the clock and CS signal are only present, when data is send (only exception is the continuous SPI clock mode). Because of that both buffers have the same size and the user has to fill the tailing bytes with dummy data. If we would have defined a dummy byte, according to Murphy's law, there is definitely one sensor out there that doesn't like that particular byte.

That said there are low-level APIs provided, that might be a better choice to solve your problem. For example: If the difference in the buffer size is quite big, you can write the command as array of 2 bytes (Cy_SCB_SPI_WriteArray) and then add a for-loop to write the tailing dummy bytes (Cy_SCB_SPI_Write) until the message size is reached. Wait until all data is send and the sensor data is received (Cy_SCB_GetNumInRxFifo returns the data size) you can read the data with Cy_SCB_SPI_ReadArray.

The Signal timing of the SPI is fixed and can be seen in the Architecture TRM of the MCU family.

regards,

Achim

View solution in original post

0 Likes
3 Replies
BragadeeshV
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hi user_103652434​,

You can use software chip select to drive CS line from high to low/ low to high instead of using the SCB's CS pin. Could you please let us know the exact timing you wish to control? Timing diagrams would be really helpful.


Regards,

Bragadeesh

Regards,
Bragadeesh
0 Likes
WeGa_288606
Level 4
Level 4
25 sign-ins 10 sign-ins 5 sign-ins

Hi,

I am not sure I understand this suggestion very well as the SCB HW/SCB API seems to have its own "internal" timing for managing the SPI rx/tx FIFO contents as function of the clock of course no? If we used a software pin function ( I am assuming you mean treat the CS pin as GPIO pin in your response) we would have to further coordinate the timing of the FIFO transfers that are abstracted by the SCB HW/SCB API no?

A secondary related question regarding the tx/rx "size" in the Cy_SCB_SPI_Transfer() API that may help clarify the purpose of my inquiry: As of now it appears that the size must be the same for the tx/rx but for example we are dealing with a sensor that accepts a 2 byte register/command packet (tx) but returns/responds (rx) with 3 bytes or more depending on the command i.e. "single byte read mode" returns 3 bytes or "burst read mode" returns multiple bytes until CS line is set high etc.... So we are trying to understand how to better control the CS line. We are using a SCB with 4 CS lines and this specific SCB has 4 SPI sensors wired to it so we plan on controlling 4 sensors with one SCB. In fact we will be controlling 4 more sensors on a second SCB as well.

I realize that we can use:

Cy_SCB_SPI_Transfer(MyHW_HW, txBuffer, rxBuffer, size, &MyHW_context) as

Cy_SCB_SPI_Transfer(MyHW_HW, NULL, rxBuffer, size, &MyHW_context) or

Cy_SCB_SPI_Transfer(MyHW_HW, txBuffer, NULL, size, &MyHW_context)

but this seems to perhaps limit the use of the API to sensors that have rx/tx of the same size which as far as I have seen are very few now a days perhaps? Or using buffers of the same size by sending dummy bytes which just take up more time I suppose. Or have to use seperate read/write functions. All perfectly OK with us but just looking for insight on use of the SPI/SCB/API efficiently.

I do not have specific timing diagrams. I am honestly just making effort to understand Cypress's "design intent" and "use intent" for the SPI SCB/SPI API. We can read/write to the sensor using the standard API but it seems like we have no control over the CS line nor its timing in case we do need it when trying to read/write from 8 sensors over two SCBs. Of course breaking up the API due to difference in rx and tx size is also interesting on timing control etc....

Thank you for the help.


Wess

0 Likes

Hi Wess,

The reason the SPI transfer is using the same length for rx and tx buffers is based on the SPI protocol, as it requires the SPI clock and CS signal to be present when receiving data. In our SCBs the clock and CS signal are only present, when data is send (only exception is the continuous SPI clock mode). Because of that both buffers have the same size and the user has to fill the tailing bytes with dummy data. If we would have defined a dummy byte, according to Murphy's law, there is definitely one sensor out there that doesn't like that particular byte.

That said there are low-level APIs provided, that might be a better choice to solve your problem. For example: If the difference in the buffer size is quite big, you can write the command as array of 2 bytes (Cy_SCB_SPI_WriteArray) and then add a for-loop to write the tailing dummy bytes (Cy_SCB_SPI_Write) until the message size is reached. Wait until all data is send and the sensor data is received (Cy_SCB_GetNumInRxFifo returns the data size) you can read the data with Cy_SCB_SPI_ReadArray.

The Signal timing of the SPI is fixed and can be seen in the Architecture TRM of the MCU family.

regards,

Achim

0 Likes