SPI transfers with continuous PCS on K22 using PE

[scottm]

I'm attempting to set up SPI transfers on a K22 using PE and the SendBlock function, and I need PCS to be continuously asserted during the transfers.  The slave device is slow to wake up, so the PCS to SCK delay has to be relatively high.  It appears that each byte is being sent as a separate transmission.  I believe that PCS is being de-asserted briefly, but someone borrowed my fast logic analyzer and the one I'm left with won't pick it up.  I'd set tDT to extend the time between transfers to be sure, but I can't find tDT anywhere in PE.

I'm seeing a delay between bytes equal to the time I configured for the PCS to SCK delay, and that's the big problem.  It makes the transfers very slow, and I can't reduce the delay time without causing wake-up problems for the slave.

So...

1) How do I keep PCS low during a complete block transfer, short of manual GPIO control?

2) Is tDT configurable in PE?  I'm going to need it later.

Thanks,

Scott

[xiangjun_rong]

Hi,Scott,

I see that you want to control the interval time between two SPI transmission, it is okay if you set the SPI of K22 as master mode and generate PCSx signal automatically  to select the slave SPI. From low level register setting, you can change the PDT and DT bits in SPIx_CTARn register to control the interval.

You can set up  the SPIx_CTARn register directly in SPI initialization stage. If you do want to use PE, you can add the "fsl_dspi_hal" bean and use the macro "DSPI_HAL_SetDelay" to set up the SPIx_CTARn register. Of course, the "fsl_dspi" bean does not have location to set up the delay.

Hope it can help you

BR

XiangJun Rong

[scottm]

The tDT issue is secondary - lack of control right now only affects my ability to diagnose the larger problem, which is that each byte transmitted is treated as a separate transmission.  47.4.4.3 in the reference manual says the CONT bit in the SPI command controls this, and if I'm reading it right, the driver has to de-assert PUSHR[CONT] on the last frame.  Does the PE driver do this?

For my purposes, the issue is moot, at least for now.  I've been able to eliminate the slow SPI slave from the design.  I'd still like to know how this is supposed to work.

Thanks,

Scott

[xiangjun_rong]

Hi, Scott,

The maximum frame size is 16 bits for each transfer, if you want to transfer more bit in one frame, you have to use the CONT bit in SPIx_PUSHR. For example, you want to transfer 48 bits data, you have to write the SPIx_PUSHR 3 times so that the SPI can transfer 3 times, in the first/second times, you have to set the  CONT bit when you write a 32 bits data to the SPIx_PUSHR, in the third transfer, you have to clear the CONT bit so that the /PCSx pin can generate the deassertive signal to deselect the slave automatically between two 48 bits data transfer. You can write the SPIx_PUSHR register directly. If you do want to use SDK function, you have to add the fsl_dspi_hal1 bean and use the macro:

////////////////////////////////////////////////////////////////////////////////////////////////

void DSPI_HAL_WriteDataMastermode(SPI_Type * base,

                                  dspi_command_config_t * command,

                                  uint16_t data);

/*!

* @brief Writes data into the data buffer, master mode and waits till complete to return.

*

* In master mode, the 16-bit data is appended to the 16-bit command info. The command portion

* provides characteristics of the data such as: optional continuous chip select

* operation between transfers, the desired Clock and Transfer Attributes register to use for the

* associated SPI frame, the desired PCS signal to use for the data transfer, whether the current

* transfer is the last in the queue, and whether to clear the transfer count (normally needed when

* sending the first frame of a data packet). This is an example:

   @code

    dspi_command_config_t commandConfig;

    commandConfig.isChipSelectContinuous = true;

    commandConfig.whichCtar = kDspiCtar0;

    commandConfig.whichPcs = kDspiPcs1;

    commandConfig.clearTransferCount = false;

    commandConfig.isEndOfQueue = false;

    DSPI_HAL_WriteDataMastermodeBlocking(base, &commandConfig, dataWord);

   @endcode

*

* Note that this function does not return until after the transmit is complete. Also note that

* the DSPI must be enabled and running in order to transmit data (MCR[MDIS] & [HALT] = 0).

* Since the SPI is a synchronous protocol, receive data is available when transmit completes.

*

* @param base Module base pointer of type SPI_Type.

* @param command Pointer to command structure

* @param data The data word to be sent

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Pls check the screenshot:

BR

XiangJun Rong

[scottm]

Ok, so going back to my original questions, I think the answers are:

1) No, PE's SPIMaster LDD (I'm not using the KSDK HAL) does not support continuous PCS using SendBlock.  Short of manual PCS control, a SPI DMA transfer with continuous PCS would require the data to be send to be interleaved in memory with SPI command words for each 16-bit data block with the CONT bit set appropriately in each.

2) DT is not configurable through PE but can be set using the SPI_CTAR_DT macros from the I/O map.  There is no PDD equivalent to DSPI_HAL_SetDelay.

Do you agree?

Thanks,

Scott

[xiangjun_rong]

Hi, Scott,

i agree with you. If you use SendBlock in PE, the PCS will toggle for each transfer, the PCS can not be continuous as you expected, in other words, you can not use sendblock, you should write one by one.

I suspect the DT can not be set up in PE, you have to use Hal or PDD to set it.

BR

Xiangjun Rong