K64F SPI MCR field PCSIS bitfield definition

[davenadler]

The reference manual for K64F SPI peripheral defines the 6-bit PCSIS field (within MCR) thus:

K64 Sub-Family Reference Manual, Rev. 3, July 2017, Chapter 50 Serial Peripheral Interface (SPI), NXP Semiconductors 1485

Determines the inactive state of PCSx.
Refer to the chip-specific SPI information for the number of PCS signals used in this chip.
NOTE: The effect of this bit only takes place when module is enabled.
Ensure that this bit is configured correctly before enabling the SPI interface.
Field Description
0 The inactive state of PCSx is low.
1 The inactive state of PCSx is high.

What does that mean?
Is one bit allocated to control each PCS?
If so, which bit controls what PCS?

Thanks in advance,
Best Regards, Dave

[davenadler]

@kerryzhou- You have not answered the question.
Again copying the manual (which I already quoted in the question above) is not helpful.
One more time:

An SPI module controls several PCS. Which PCS is used for a transfer is specified in the command field written to the PUSHR register.
The MCR register controls the overall behavior of the SPI port across different peripherals (different PCS).
As such it must control the PCS pins behavior when no transfer is in progress (when the SPI is idle).

The SDK code implies PCSIS is a bitfield, and that the documentation quoted above is incorrect:

typedef enum _dspi_which_pcs_config
{
    kDSPI_Pcs0 = 1U << 0, /*!< Pcs[0] */
    kDSPI_Pcs1 = 1U << 1, /*!< Pcs[1] */
    kDSPI_Pcs2 = 1U << 2, /*!< Pcs[2] */
    kDSPI_Pcs3 = 1U << 3, /*!< Pcs[3] */
    kDSPI_Pcs4 = 1U << 4, /*!< Pcs[4] */
    kDSPI_Pcs5 = 1U << 5  /*!< Pcs[5] */
} dspi_which_pcs_t;

Also, the documentation in section 50.3.7 PUSH TX FIFO Register In Master Mode (SPIx_PUSHR)  has a mistake:
The PCS field is an index specifying which PCS is asserted for the transfer.
The following text describing the PCS field is incorrect and should be deleted:
0 Negate the PCS[x] signal.
1 Assert the PCS[x] signal.

I believe PCSIS documentation is similarly incorrect, and should be documented as a bitfield as implied by SDK code.

Please forward this question to someone really familiar with the hardware, and confirm:
- my understanding is correct, and
- these two documentation errors will be corrected in the next manual revision

Thanks!
Best Regards, Dave

[kerryzhou]

Hi davenadler,

   Thanks for your updated information, and sorry for my later reply because of Chinese Spring Festival.

   The last time which I reply you, just tell you the detail bit information.

   To K64 SPI, it contains 6 PCS: PCS0-PCS5.

   The K64 RM SPIx_MCR[PCSIS] description is correct, PCSIS has 6bits, from bit 16 to bit21.

   It means bit 16 to bit 21 is related to the PCS0-PCS5.

   Please note, document mentioned inactive state, but the SDK mentioned active state.

  You also can find details in the SDK, eg:

#define SPI_MCR_PCSIS(x) (((uint32_t)(((uint32_t)(x)) << SPI_MCR_PCSIS_SHIFT)) & SPI_MCR_PCSIS_MASK) 

kDSPI_PcsActiveHigh = 0U, /*!< Pcs Active High (idles low). */
kDSPI_PcsActiveLow = 1U /*!< Pcs Active Low (idles high). */

You can find, when kDSPI_PcsActiveLow=1, then the code set related PCS bit to 1, it is also the inactive state of PCSx is high, means active state is low. Then the related PCS pin will be configured.

In fact, the RM is correct.

SPIX_MCR[PCSIS]: define the related PCS bit active is high or low, it is not determined used or not.

SPIx_PUSHR[PCS]: you can understanding it is used to determined the SPI data transfer is assert the PCS[x] or not.

Take the SDK code as example:

base->PUSHR = SPI_PUSHR_CONT(command->isPcsContinuous) | SPI_PUSHR_CTAS(command->whichCtar) |
SPI_PUSHR_PCS(command->whichPcs) | SPI_PUSHR_EOQ(command->isEndOfQueue) |
SPI_PUSHR_CTCNT(command->clearTransferCount) | SPI_PUSHR_TXDATA(data);

This means, this SPI transfer will use the related PCS pin, still the same, PCS in PUSHR is bit 21-16, it means PCS5-0.

So, no matter the SDK or the RM document, all correct. Just one is configure the active low or high, another is used to insert the related PCS pin function or not.

If you still have issues, you also can try to configure the related PCS pin, and use the oscilloscope to check the SPI bus wave, that will be more clear to you.

Wish it helps you!

If you still have questions about it, please kindly let me know.

Best Regards,

Kerry

[kerryzhou]

Hi davenadler,

  PCS pin : Selects an SPI slave to receive data transmitted from the module.

  PCSIS :Peripheral Chip Select x Inactive State

  Determines the inactive state of PCSx. Refer to the chip-specific SPI information for the number of PCS
signals used in this chip.
NOTE: The effect of this bit only takes place when module is enabled. Ensure that this bit is configured
correctly before enabling the SPI interface.

0 The inactive state of PCSx is low.
1 The inactive state of PCSx is high.

It means, take PCSIS= 1, the inactive state of PCSx is high, it means PCS=0 used to select the external slave chip, and will send the SPI data, PCS=1 is the inactive pin, not send SPI data.

PCSIS= 0 is reverse.

About the control the PCS, it is SPI module control it automatically, you don't need to control it. Before send and receive the data, the module will pull the PCS to the active status automatically.

Wish it helps you!

If you still have questions about it, please kindly let me know.

Best Regards,

Kerry