Looking at the SPI signals, there are brief mentions of SPI0_PCS5 in the multiplexing table (table 10.3.1) in the MK10DN512VLL10 reference manual, version 2. Is there really a SPI0_PCS5 signal? The chapter for the SPI module only shows SPI0_PCS0-SPI0_PCS4, however the SPI_PUSHR register shows PCS[5:0]. Possibly this is a holdover from the MK10DN512ZVLL10 part?
Another question, the features for the SPI mention possibly using an external mux to expand the SPI strobe signals. I'm assuming this means that when doing a SPI transfer, the PCS[5:0] can have multiple bits asserted, so that one pin can drive an enable on a decoder while others are driving the decoder inputs. Is this correct? Expanding on that, is there a way to ensure the enable line is asserted after the decoding bits?
Solved! Go to Solution.
Hi David,
Yes, you can have the SPI peripheral assert multiple chip selects. There is a bit for each chip select in the register SPIx_PUSHR[PCS] field. When you write to the PUSHR register to initiate a SPI transfer, you set each bit for the chip selects you want asserted. And yes, they will change at roughly the same time, following the timing in the documentation.
I hope that helps. Thanks
Hi David,
Yes, the MK10DN512VLL10 SPI0 provides 6 chip selects. The SPI0_PCS5 signal exists at PTB23 pin.
The SPI0_MCR register with incorrect info at reference manual, which should be from bit 16 to bit 21 PCSIS[5:0].
Customer could check K60_100MHz silicon revision 2.x header file, which using the same SPI module with MK10DN512VLL10 product:
#define SPI_MCR_PCSIS_MASK | 0x3F0000u |
#define SPI_MCR_PCSIS_SHIFT | 16 |
#define SPI_MCR_PCSIS(x) | (((uint32_t)(((uint32_t)(x))<<SPI_MCR_PCSIS_SHIFT))&SPI_MCR_PCSIS_MASK) |
Yes, you are quite right.
The SPI external chip select could be extended with using a decoder chip.
Wish it helps.
best regards,
Ma Hui
To further expand on this topic, the MK10DN512VLL10 does have PCS5 as Ma Hui stated. But it does not offer the Peripheral Chip Select Strobe feature to aid in demultiplexing the chip selects externally. The older Rev1.x silicon with a 'Z' in the part number, like MK10DN512ZVLL10, included a bit SPIx_MCR[PCSSE] for Peripheral Chip Select Strobe Enable. In the newer Rev2.x devices that do not have the 'Z' in the part number, this strobe feature was not included, and there is no PCSSE bit or supported mode. The references to the chip select strobe feature were removed from the newer reference manual. But this feature in the SPI section "Deglitching support for up to PCS with external demultiplexer" should also be removed from the Rev2.x reference manuals like document K10P144M100SF2V2RM.
Sorry for the confusion
One more demux usage question. If we use an 74HC138 demux with PCS[2:0] connected to A[2:0] respectively, and PCS5 connected to /E1, can we strobe the slaves reliably?
Hi Sean,
For the 100MHz K10 Rev2.x devices without the 'Z' in the part number, like MK10DN512VLL10, the SPI peripheral does not support the Peripheral Chip Select Strobe Enable (PCSSE) feature. PCS5 is another SPI chip select signal, and does not offer the strobe feature. The PCS5 signal will be transitioning at the same time as the other chip select outputs fed into the demux. If the transition timing of those chip selects causes an issue with the SPI slaves, then I recommend using software-controlled chip selects using GPIO, and using a GPIO as the strobe/enable for the demux. Or another option is to use a Kinetis MCU with the PCSSE feature.
Thanks
Thank you Derek and Ma Hui, I was able to get SPI0_PCS5 to show up on PTB23, thanks for the update on the documentation. Here's another question: If all these bits are defined as strobes, can you define multiple bits to be asserted, and will these bits all change state at roughly the same time? Here's what I'm thinking. Even though the PCSSE feature is not available in this part, let's say we do have PCS5 defined, and the idle state is high. If we then defined strobe patterns as Sean described, and had PCS5 driven low during the SPI, then in hardware we could delay PCS5 slightly using a resistor and capacitor to latch the decoder. Is this conceivable?
Hi David,
Yes, you can have the SPI peripheral assert multiple chip selects. There is a bit for each chip select in the register SPIx_PUSHR[PCS] field. When you write to the PUSHR register to initiate a SPI transfer, you set each bit for the chip selects you want asserted. And yes, they will change at roughly the same time, following the timing in the documentation.
I hope that helps. Thanks
Thanks Derek, it seems to be working and I can use it with a decoder despite not having the PCSSE feature.