MQX 4.1: Use Spi with Chip Select Strobe Enable

[arnogir]

Hello

I'm using MQX 4.1 on some Kinetis µC (K70, K60...)

I'm looking for a way to use the SPI Chip Select signal with Strobe option.

DataSheet indicate SPIx_MCR_PCSSE have to set to 1. By this way PCS5 become a strobe signal.

§53.2.4 of K60p144 datasheet:

When the DSPI is in master mode and the MCR[PCSSE] bit is set, the PCSS signal acts

as a strobe to an external peripheral chip select demultiplexer, which decodes the PCS0 -

PCS4 signals, preventing glitches on the demultiplexer outputs.

But I not found in the MQX_IO_USer_Guide.pdf any way to use this mode.

Are they a IO_Ctl command to do this? I read in the MQX code, I'm not find a line which set SPI_MCR_PCSSE bit.???

Thank for your help

:smileyhappy:

[RadekS]

You are right, strobe option (PCSSE bit) was not used in DSPI driver.

In fact DSPI driver offers two options how to work with CS signals.

In first option, CS signals are generated directly by SPI module when driver modify Peripheral Chip Select x Inactive State value in SPIx_MCR[PCSIS]. In this case strobe option was not implemented however you can use second option.

In second option, you can install your CS callback which will be executed at every start and end of data transfer. In that case you can implement strobe signal by driving GPIO line after all CS signal are set.

In fact in this case you are not limited by number of CS signals and you case use any number of GPIO lines instead of demultiplexor.

MQX already contains SPI example code with this option (on base of BSP_SPI_MEMORY_GPIO_CS macro).

I hope it helps you.

Have a great day,
RadekS

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[chenlifei]

Hi Radek Sestak:

    I'm using K64 in my project.

    I think that you are quite familiar with SPI module so may I ask you a question: The code in MQX BSP IS CORRECT to drive PCSn High or Low?

    Before each read/write , it call function  _dspi_setparam ,and in this function ,the CS pin is set to low:

    _dspi_setparam{

    ...

    /* Set CS signals */
    dspi_ptr->MCR = (dspi_ptr->MCR & ~DSPI_MCR_PCSIS_MASK) | DSPI_MCR_PCSIS(~(params->CS));

    return SPI_OK;

}

   Actually,the CS pin is really set to LOW!!

  But,in the K64 RM(K64P144M120SF5RM) Page  1452,it descripe the PCSIS is:

"

  Peripheral Chip Select x Inactive State

  Determines the inactive state of PCSx.

  0 The inactive state of PCSx is low.

  1 The inactive state of PCSx is high.

"

The key of my question is that it's the INACTIVE STATE OF PCSx，not the ACTIVE. Yes it achived the goal to make PCS low,but,it's the right method ? ?

I thought that the SPI moudule can drive the PCS pin to LOW automatically when start one transfer and set the PCS High once the last byte send out,if we set all relevant register including the PCSIS in MCR.Is my thought is right (I'm not verify it via my code yet )?

Could you slove my doubt? thank you a lot and forgive my poor English!

[RadekS]

Hi Chen Lifei,

I do not support MQX already some time. So, my answer may not be very precise.

You are right, the DSPI module offers automatic driving CS pins. However, this feature has also few disadvantages.

1. The number of available hardware CS pins is limited (per module, see RM).
2. The only trigger point is the start of data transfer (missing transfer complete flag). So, we must specify the delay before data start and delay to the end of transfer (we should take clock tolerances for final calculation into account). Unfortunately, this delay takes effect also when longer stream is transmitted despite in fact, that we do not toggle with CS pin between transmitted words. So, these delays effectively decrease SPI throughput when we transfer bigger pack of data.

The typical use cases are either transmitting few bytes, where total SPI throughput is almost irrelevant or sending a big pack of data, where SPI throughput is critical.

These disadvantages are solved by MQX DSPI driver by software workaround. The MQX DSPI driver does not use automatic driving CS pins by DSPI module, but it toggles with PCSIS bit for immediate CS pin value change. The INACTIVE/ACTIVE description is here irrelevant since we use that bit for direct driving of CS pins level instead of original purpose = the initial configuration or active/inactive level.

The CS signals for MQX DSPI driver are not limited by hardware (you may have for example 20 CS signals if you wish).

Also, the delays will not decrease SPI throughput for a big pack of data.

Another main advantage is that MQX SPI driver may be accessed from several threads “simultaneously” (The MQX SPI driver finish current transfer first). The price for that solution is small software overhead.

Note: The SPI_legacy driver does not use this software workaround.

I hope it helps you.

Have a great day,
Radek

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[arnogir]

Hello

Thank to inform me about this solution.

But in fact, the second solution "use" some software time whereas K60 can do it directly by hardware just in modify a register configuration!

So I think I will customize MQX to add this possibility (i.e by IOCtl)

May be this option is scheduled in a next MQX release?

[RadekS]

Yes, you are right. CS callback presents additional software overhead. However also first option presents software approach, therefore I suppose minimum difference between these approaches.

Unfortunately pure hardware solution at DSPI module solution (presented in reference manual) has several disadvantages therefore we used two optional software solutions instead of pure hardware solution (like it was used in legacy SPI driver).

In most cases, typical uses are presented by two extremes:

1. You send just few bytes once per time and typically you don’t care about SPI bus throughput.
2. You transfer big amount of data as fast as possible, but in this case we don’t change CS signals very often and delay in CS signal settings are negligible in compare with transfer time.

This software overhead is small price for much wider functionality and workaround DSPI module limitations.

We don’t have plan for adding strobe option to the current DSPI driver. MQX4.2 will be released very soon (probably end of April 2015) and according current plant it will be last “Classic” MQX release.

MQX for KSDK uses SPI driver from KSDK.

[arnogir]

Many thank for all your information.

I will see if I get a "Software" or "hardware" solution.

[DavidS · Accepted solution]

Hi Arno,

There is much history with the MQX SPI driver but the summary of it is that the SPI module is very flexible in how it can be configured to operate.  The MQX driver has been developed to allow for most of those configurations but in order to do that the compromise was to not use the inherent hardware supported chip select method.

That being said, you can modify the driver to use the hardware supported chip select for your specific implementation.

Attached is one example of code I did this for about a year ago for the twrk60d100m.

Regards,

David