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

cancel
Showing results for 
Search instead for 
Did you mean: 

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

Jump to solution
283 Views
Senior Contributor II

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

 

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

128294_128294.JPGDSCF0061.JPG

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

Labels (1)
1 Solution
4 Views
Senior Contributor II

So, I have gotten SD Cards working with the K22F with SPI.  I put the code on this https://community.freescale.com/message/612390 thread.

myke

View solution in original post

3 Replies
5 Views
Senior Contributor II

So, I have gotten SD Cards working with the K22F with SPI.  I put the code on this https://community.freescale.com/message/612390 thread.

myke

View solution in original post

4 Views
NXP TechSupport
NXP TechSupport

Hi Myke,

I found you posted similar thread in HELP!!! Last bit of Kinetis DSPI Byte Transfer is Trucated , do are they the same issue? is it fixed?


Have a great day,
Kan

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

0 Kudos
4 Views
Senior Contributor II

Hi Kan,

Yes, it is the same issue and it's fixed with declaring the variable:

uint32_t spi0_ctar0_reg;

and then, after the "DSPI_DRV_MasterConfigureBus" statement, put in:

  spi0_ctar0_reg = SPI0_CTAR0 & 0xFF3F0FFF;  //  Fill out last bit of each byte xfer

  spi0_ctar0_reg = spi0_ctar0_reg | 0x00C01000;

  SPI0_CTAR0 = spi0_ctar0_reg;

I can obviously simplify the three statements into one without a variable, but this allowed me to observe the progress of the operations. 

The values for the changed CTAR0 bits (the PCSSK and CSSK fields in particular) were determined by trial and error (get the GDB plugin that allows you to modify system registers as it will make actions like this a *lot* easier).  The K22F's RM was used for information on the CTAR0 register. 

Regards,

myke

0 Kudos