SDK K02, Spi Delay After transfer (Tdt)

[arnogir]

Hello,

I'm using a k02FN64VLH10.

I want use the SPI to transfer 4 bytes to a analog converter. The ChipSelect signal must not be unasserted between theses 4 bytes.

Then in McuXpresso SDK configuration for the Spi peripheral, I configured like this:

Then the DSPI_MasterSetDelayTimes is called from DSPI_MasterInit with following parameters:

Base : SPI0

WhichCTAR = CTAR0

whichDelay = kDSPI_BetweenTransfer

srcClock_Hz = 49999360

delayTimeInNanoSec = 250.

Then At the end of this function, the function DSPI_MasterSetDelayScaler is called with:

prescaler = 3 (= Div/7)

scaler = 0 !!...

Then I called the functin to start transfer like this:

 MasterXfer.txData      = Buffer;
  MasterXfer.rxData      = Buffer;
  MasterXfer.dataSize    = NumberRegsisterToRead + 2;
  MasterXfer.configFlags = kDSPI_MasterCtar0 | DV_ADS1248_SPI_PCS | kDSPI_MasterPcsContinuous;  
  DSPI_MasterTransferBlocking(DV_ADS1248_SPI_CHANNEL, &MasterXfer);

But on the scope, I get 8 clock pulse, then the following 8 start immediately, there is a very small time (80ns) instead of the configured value (=250ns = 1 clock pulse)...

To resolve the problem, I must change the ConfigFlag by remove the kDSPI_MasterPcsContinuous. By this, I have good clock, but the Chip select signal is deaserted between each byte.

Then I rout the Chip Select pin to a normal GPIO I forced to 0. But I get a warning into the SDK because PCS0 is not routed...

How have a continous ChipSelect with a correct Tdt? I try to change DT to the max (16) and PDT to 3 to have the maximum time without success...

[diego_charles]

Hello,  Arnaud Girard

Thank you for showing your settings of DSPI0. 

I´m working on your question.

Just to make sure if I understand correctly, you desire to set specifically this parameters

Baud rate =2,000,000

the time between 8  SCK clocks, that indicate each byte transfer  = 250nS.

Maintain the Chip selected with PCS0, during all the  4-byte transfer. 

PCS to SCK delay time = 10ns, or the least. 

SCK to PCS delay time = 7nS, or the least. 

But the time between the 8 SCK cycles or clocks is less than the desired, or the PCS0 (chip select) changes each byte transfer. 

Could you confirm?

Best regards, Diego. 

[arnogir]

The problem was the time between each byte.

The PCS0 must be maitain betwwen each byte (with flag kDSPI_MasterPcsContinuous)

But with this, the field "After the SCK delay time" have no action.

In fact, it is the "PCS to SCK "and "Last SCK to PCS" which have both effect on the time between each byte. Like if the PCS signal was managed between each byte. Then I no found where the "After the SCK delay time" was effect...

[diego_charles · Accepted solution]

Hello,  Arnaud Girard 

Thank you for your reply.  

In this case, to achieve the desired time between byte transfers (250nS)   you will need to increase the

 PCS to SCK (tCSC) and SCK to PCS (TASC) delays.

Please note that when  PCSx is asserted during all the byte transfers, which is  continuous chip select flag enabled,

the time between each byte transfer won't be determined by Time Delay transfer equation (Tdt= 1/fp * PBD*DT), 

 It will be the addition of PCS to SCK and SCK to PCS delays. Please refer to the following image. 

 That could help to explain why after you set the DT and PBD prescalers, (of CTAR0 register) to their

 maximum values, to increase Tdt,  the time between transfer did not increase.

As you mentioned before, after disabling the continuous chip select you

get the desired  (Tdt),  but the chip select signal gets

de-asserted. As shown in the following image.

To get further information please refer to chapter 38.4.4.5 Continuous Selection Format of the device reference manual.

Please let me know if this information is useful. 

Best regards, Diego. 

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

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.

-------------------------------------------------------------------------------

[arnogir]

Thank for your complete answer which explain my observations.

I read the datasheet, but not enought! I had not take enought attention to these chronogrames.

Thank