AnsweredAssumed Answered

HELP!!! Last bit of Kinetis DSPI Byte Transfer is Trucated

Question asked by Myke Predko on Jan 14, 2016
Latest reply on May 31, 2016 by Diego Colombo

Like • Show 0 Likes0
Comment • 7

I have also put this question on the SDK forum, but I need to get a reply ASAP on this issue.

I'm struggling with trying to get SD Cards working with the K22F and I'm wondering about the dspi clock.

As I mentioned in a previous question, the last bit of a dspi byte transfer is truncated as you can see in this quick and dirty screenshot:

The bottom line is the dspi sck and you can see that the "low" half of the cycle is truncated into the first bit of the next transfer.

The dspi was selected from PE with a clock speed of 375kHz with Clock cfg.4 on a FRDM-k22F board.

I'm looking around and can't find any reason of what I'm doing wrong, 375kHz is a "Possible setting" so I presume that means that the clock is divided evenly (although evidence suggests this is not the case).

Can anybody help?

Thanx,

myke

David Sherman Jan 15, 2016 12:52 PM

Correct Answer

It appears you need to add some time before starting the next SPI frame, this is done in the CTAR register through the PCSSCK and CSSCK fields. That way you can make sure the clock period isn't too short. Just had to fix this myself on a K10.

See the reply in context

No one else had this question

Outcomes

David Sherman Jan 15, 2016 12:52 PM

1 person found this helpful

Actions

Myke Predko @ David Sherman on Jan 17, 2016 10:45 PM

Hi David,

Thank you for the pointer - I was able to get the final clock looking pretty good:

A couple of things:

To dynamically read & change the bits of CSSCK & PCSSCK, I found: http://mcuoneclipse.com/2014/05/29/how-to-add-register-details-view-in-eclipse/ which is a plugin & patch that allows register bits to be manipulated from KDS (Eclipse). I believe CW had/has this capability but it's nice to have it on KDS.
If you look at the waveform above, you'll see the data spikes at the end of the 8th clock cycle high. Is there any way to remove that? (It's the purist in me.)

Thanx!

myke

Actions

Diego Colombo Jan 15, 2016 3:19 PM

Hi Myke

it reminds a similar problem that i had with KL15.

I have not the code on this PC,and i'm not shure at all that the situations are related.

I wrote my own routine for transmitting n bytes ,accessing directly to SPI register ,i had to use a GPIO pin as SPI CS,because that SPI (SPI0)was not able to keep CS costantly low during transfer of multiple bytes,and this was requested by the external peripheral.The original CS pin was left free.

At first attempts,after copied the last byte in the data register i checked SPI1_S & SPI_S_SPTEF_MASK ,but doing that is simply check that the output buffer is free, once it has moved the byte in the output shift register,but the transmission on pin could be still running,

the code at that point was faster than the shifting mechanism,so i issued another transmission too early,and thelast byte was truncated.

The workaround that i did was ,once the last byte was launched ,to check the original CS pin level as it was a GPIO:

while(!(GPIOD_PDIR & 0x10));

because differently than SPTEF ,the CS pin goes inactive only when all the bits are physically shifted out on pin.

Probaly it was not the better way to do what i needed,but this is the only thing that i can remember that could have something to do with your problem

Good luck

Diego

Actions

Myke Predko @ Diego Colombo on Jan 17, 2016 10:49 PM

Hi Diego,

Could I see your code? I'm curious to see if it avoids the truncated bit issue that I started with as well as the spike shown in the 'scope shot above.

I do use a GPIO for !CS for the same reasons that you point out above. BUT, I monitor the output of the bytes before continuing by using the code:

for (wordsTransferred = 0; (kStatus_DSPI_Busy == DSPI_DRV_MasterGetTransferStatus(DSPI_MASTER_INSTANCE, &wordsTransferred)) ||

(wordsToTransfer != wordsTransferred);) {

}

As I found that "kStatus_DSPI_Busy" was being returned BEFORE the last byte had been sent.

Thanx,

myke

Actions

David Sherman @ Myke Predko on Jan 18, 2016 9:30 AM

If it helps, I'm using the CONT and EOQ bits in the PUSHR register to make sure the /CS signal stays asserted when transferring multiple bytes, I haven't seen the data line glitches that Myke is seeing. Also, If you're using a polling routine to check for byte transmission, poll on the RFDF flag. Even if you're not receiving bytes, polling on that would guarantee that the byte is transmitted AND one is received. Read the POPR register and write to the RFDF bit to clear before transmitting the next byte.

I believe the KL spi module is the same as the one on the KE part; I had to use GPIO to control /CS as well. It's not as sophisticated as the K10/K20 spi module where you can tell it there are more bytes to transfer.

1 person found this helpful

Actions

Diego Colombo @ Myke Predko on Mar 8, 2016 1:42 AM

Sorry,i missed your request.Lot of time is passed but today i'll try to find the codeit (is not in this PC)

Actions

Diego Colombo @ Myke Predko on May 31, 2016 11:20 AM

Mark..sorry but i have no way to have the code.I can't acced to that PC

Furthermore i dont know no more how to attach files.Something looks changed.

Sorry

Diego

Actions

7 Replies

David Sherman Jan 15, 2016 12:52 PM
Unmark Correct
Correct Answer
It appears you need to add some time before starting the next SPI frame, this is done in the CTAR register through the PCSSCK and CSSCK fields. That way you can make sure the clock period isn't too short. Just had to fix this myself on a K10.
1 person found this helpful
Like • Show 0 Likes0
Actions
- Myke Predko @ David Sherman on Jan 17, 2016 10:45 PM
  Mark Correct
  Correct Answer
  Hi David,
  
  Thank you for the pointer - I was able to get the final clock looking pretty good:
  
  A couple of things:
  To dynamically read & change the bits of CSSCK & PCSSCK, I found: http://mcuoneclipse.com/2014/05/29/how-to-add-register-details-view-in-eclipse/ which is a plugin & patch that allows register bits to be manipulated from KDS (Eclipse). I believe CW had/has this capability but it's nice to have it on KDS.
  If you look at the waveform above, you'll see the data spikes at the end of the 8th clock cycle high. Is there any way to remove that? (It's the purist in me.)
  
  Thanx!
  
  myke
  Like • Show 0 Likes0
  Actions
Diego Colombo Jan 15, 2016 3:19 PM
Mark Correct
Correct Answer
Hi Myke
it reminds a similar problem that i had with KL15.
I have not the code on this PC,and i'm not shure at all that the situations are related.

I wrote my own routine for transmitting n bytes ,accessing directly to SPI register ,i had to use a GPIO pin as SPI CS,because that SPI (SPI0)was not able to keep CS costantly low during transfer of multiple bytes,and this was requested by the external peripheral.The original CS pin was left free.
At first attempts,after copied the last byte in the data register i checked SPI1_S & SPI_S_SPTEF_MASK ,but doing that is simply check that the output buffer is free, once it has moved the byte in the output shift register,but the transmission on pin could be still running,
the code at that point was faster than the shifting mechanism,so i issued another transmission too early,and thelast byte was truncated.

The workaround that i did was ,once the last byte was launched ,to check the original CS pin level as it was a GPIO:
while(!(GPIOD_PDIR & 0x10));
because differently than SPTEF ,the CS pin goes inactive only when all the bits are physically shifted out on pin.

Probaly it was not the better way to do what i needed,but this is the only thing that i can remember that could have something to do with your problem

Good luck

Diego
Like • Show 0 Likes0
Actions
- Myke Predko @ Diego Colombo on Jan 17, 2016 10:49 PM
  Mark Correct
  Correct Answer
  Hi Diego,
  
  Could I see your code? I'm curious to see if it avoids the truncated bit issue that I started with as well as the spike shown in the 'scope shot above.
  
  I do use a GPIO for !CS for the same reasons that you point out above. BUT, I monitor the output of the bytes before continuing by using the code:
  
      for (wordsTransferred = 0; (kStatus_DSPI_Busy == DSPI_DRV_MasterGetTransferStatus(DSPI_MASTER_INSTANCE, &wordsTransferred)) ||
          (wordsToTransfer != wordsTransferred);) {
      }
  
  As I found that "kStatus_DSPI_Busy" was being returned BEFORE the last byte had been sent.
  
  Thanx,
  
  myke
  Like • Show 0 Likes0
  Actions
  - David Sherman @ Myke Predko on Jan 18, 2016 9:30 AM
    Mark Correct
    Correct Answer
    If it helps, I'm using the CONT and EOQ bits in the PUSHR register to make sure the /CS signal stays asserted when transferring multiple bytes, I haven't seen the data line glitches that Myke is seeing. Also, If you're using a polling routine to check for byte transmission, poll on the RFDF flag. Even if you're not receiving bytes, polling on that would guarantee that the byte is transmitted AND one is received. Read the POPR register and write to the RFDF bit to clear before transmitting the next byte.
    
    I believe the KL spi module is the same as the one on the KE part; I had to use GPIO to control /CS as well. It's not as sophisticated as the K10/K20 spi module where you can tell it there are more bytes to transfer.
    1 person found this helpful
    Like • Show 0 Likes0
    Actions
  - Diego Colombo @ Myke Predko on Mar 8, 2016 1:42 AM
    Mark Correct
    Correct Answer
    Sorry,i missed your request.Lot of time is passed but today i'll try to find the codeit (is not in this PC)
    Like • Show 0 Likes0
    Actions
  - Diego Colombo @ Myke Predko on May 31, 2016 11:20 AM
    Mark Correct
    Correct Answer
    Mark..sorry but i have no way to have the code.I can't acced to that PC
    Furthermore i dont know no more how to attach files.Something looks changed.
    
    Sorry
    
    Diego
    Like • Show 0 Likes0
    Actions

HELP!!! Last bit of Kinetis DSPI Byte Transfer is Trucated

Outcomes

Related Content

Recommended Content

Incoming Links