K22: SPI with GPIO PCS - All CTAR settings still valid?

cancel
Showing results for 
Search instead for 
Did you mean: 

K22: SPI with GPIO PCS - All CTAR settings still valid?

453 Views
troelsoesteraa
Contributor II

Hi,

Device: MK22FN256VLL12.
So I ran out of hardware PCSs for the hardware I'm working on - for both SPI0 and SPI1.
I can see it is possible to use any GPIO as "manual" toggling before setting the PUSHR register and starting the transfer.

My question is: Are custom timings such as ASC and PSC still implemented and used when it is specified in the CTAR, and the specific CTAR is selected in PUSHR - BUT I toggle a GPIO for chip-selection? If so, how does this work, exactly?
If not, what parts of the CTAR applies, when I use a GPIO for chip-selection - surely basics as the SPI mode (CPHA,CPOL) are obeyed?

Thanks a lot.

Tags (4)
0 Kudos
3 Replies

142 Views
xiangjun_rong
NXP TechSupport
NXP TechSupport

Hi, Troels,

I see your problem that you want to use GPIO as chip select instead of SPI_PCSx.

When the SPI module is designed, the SPI_PCSx had been thought as the chip select to access slave spi in default. Anyway, I think  the timing features defined in CTARx is always valid, and the CPHA,CPOL features are also valid.

I think it is okay to use GPIO as chip select to access slave spi module, but you can NOT use FIFO mode, you have to disable FIFO. the SPI0 has 4 deepth FIFO for both receiver and transmitter, the SPI1 does not support FIFO mode itself.

Because FIFO mode is disabled, the SPI master generates the timing only after you write the SPIx_PUSHR register.

This is the sequence of firmware.

1)configure the SPI module and disable FIFO by setting the DIS_TXF in SPIx_MCR register.

2)configure GPIO pin

3)clear GPIO

4)after a programmable delay, write the SPIx_PUSHR, the SPI will generate timing based on your predefined features in CTARx.

5)use interrupt or polling modes, check TCF or RFDF bits in the SPIx_SR to check if the transmitter has finished, if the flag is set, read data, set GPIO, delay some time.

6)repeat (3) operation.

This is my opinion, pls have a try

Hope it can help you.

BR

Xiangjun Rong

0 Kudos

142 Views
troelsoesteraa
Contributor II

Hi Xiangjun Rong,

Thanks for your reply, it is much appreciated.

I already did it the way you also suggested - and it works fine. FIFO is disabled.I was just a bit puzzled by how the various timings that define the edge of SCK compared to PCS can be valid when there SPI module doesn't know when the GPIO toggles compared to when PUSHR is written.

But from my testing, it seems as if the CSSCK setting is obeyed, as illustrated below. Here, I am running the SPI clock at 1.875 MHz, with a CSSCK of 16, 32 and 64. In all instances, the value of 255 is sent from the MCU.

SPI_CSC_16.PNG

SPI_CSC_32.PNG

SPI_CSC_64.PNG

Any changes to the ASC setting are however, ignored. So my interpretation of this is that
the CSSCK timing is with regards to when the PUSHR register is written, and not when the PCS (if used) was de-asserted.  By following this logic, it also makes sense that ASC cannot be applied when using a GPIO for CS, since how should it doesn't have any control of the CS?!

0 Kudos

142 Views
xiangjun_rong
NXP TechSupport
NXP TechSupport

Hi, Troels,

I think the ASC parameter is valid, the ASC is the delay between the last edge of SCK and the negation of PCS, because the PCS is replaced by GPIO, so you can not observe the ASC effect. The DT is invalid because you do not use FIFO mode.

Hope it can help you

BR

Xiangjun Rong

0 Kudos