Are 32-bit SPI slave frames possible on MK60DN512VMD10

cancel
Showing results for 
Search instead for 
Did you mean: 

Are 32-bit SPI slave frames possible on MK60DN512VMD10

980 Views
piotrfyda
Contributor I

Hello NXP,

I have 3 questions concerning the reference manual for the Kinetis MK60DN512VMD10 used in the TWR-K60D100M

      Document Number: K60P144M100SF2V2RM Rev. 2 Jun 2012

      K60 Sub-Family Reference Manual, Rev. 2 Jun 2012 -  Preliminary General Business Information

Question 1:

I'm trying to connect a 24-bit SigmaDelta ADC converter PCM1804 (master) to SPI (slave) on Tower_TWR-K60D100M.

It sends a 32-bit frames and so it is incompatible with KSDK_1.3.0 driver in

  ...\Freescale\KSDK_1.3.0\examples\twrk60d100m\driver_examples\dspi\...

which accepts only 16-bit frames.

So I've started to program the SPI "manually" and I found out that there are problems!

The manual K60P144M100SF2V2RM Rev.2  says explicitly, that 32bit frames are supported in the in slave mode.:

Figure 50-1, page 1402 - shows 32-bit path from Shift Register  to RX FIFO

§50.3.4, page 1418 - shows SPIx_CTARn_SLAVE where FMSZ has 5 bits == 32bits frame size

§50.3.9, page 1427 - says:

POPR is used to read the RX FIFO. Eight- or sixteen-bit read accesses to the POPR have

the same effect on the RX FIFO as 32-bit read accesses.

§50.4.2, page 1431 - says:

the SPI frames can be 32 bits long

My test program gives only max. 16 bit frames which I can read.

The highest bit of FMSZ (bit 31) has no influence on the received data in the RXFIFO and POPR.

I see in the RXFIFO the high-word and low-word of a 32-bit frame (and I could assemble the 32-bit frame), but the Reference Manual says I should get 32-bit result in POPR.

So what is true ???

Question 2:

The manual K60P144M100SF2V2RM Rev. 2  shows (§50.3.1, page 1410)  the SPIx_MCR layout:

- bit 25 is ROOE and bits 24,23,22 are reserved

in the old manual, there was

- bit 25 was PCSSE and ROOE was on bit 24, bits 23,22 were reserved

Kinetis Desing Studio 3.1.0 shows in EmbSys Registers the "old" layout (MK60D10 chip selected)

So what is true ???

Question 3:

I have downloaded 2 versions of K60P144M100SF2V2RM Rev.2,

one is 14.229KB big - another only 13.853KB !

(they seem to be the same... but who knows - I'm not going to compare page by page...)

So how can it be ???

A version is A VERSION and should have always the same size (at least in my opinion) !

Thanks in advance for a quick responce.

best regards

Piotr Fyda

0 Kudos
6 Replies

247 Views
Jorge_Gonzalez
NXP Employee
NXP Employee

Hello Piotr Fyda:

Regarding your K60 questions:

1) It must be possible to receive 32-bit SPI frames. Be careful not to have an open view of the SPIx_POPR register in the debugger, otherwise the corresponding data in the RX FIFO might be lost and the part of your code which reads the received values will fail.

If it still fails please share your code or project to give it a check.

2) I think you are right about this. I will report it to our developers.

3) Could you please point me to the site where you got the manuals?

In our official NXP website I can only see one file for K60P144M100SF2V2RM.pdf:

K60_100 |Kinetis K60 100 MHz MCUs|NXP

Maybe you also downloaded the Reference Manual K60P144M100SF2RM.pdf. This is for an old revision of the K60_100 MHz silicon.


Best regards,
Jorge Gonzalez

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

0 Kudos

247 Views
piotrfyda
Contributor I

Hello Jorge ,

First - thank you for your response and informing the developers about Point 2!

Concerning my remaining points 1) and 3):

Ad 1)

You write:  Be careful not to have an open view of the SPIx_POPR register in the debugger, otherwise the corresponding data in the RX FIFO might be lost...

It is for the first time I meet such a warning !

I assumed that debugger can be used to see what's going on in the system and it does not have impact on behaviour of the hardware (except for the real time performance of course).

You write also: It must be possible to receive 32-bit SPI Frames.

It is not - 32-bit Frames do not work on MK60DN512VMD10 - you get 2 16-bit Frames and the  highest bit of FMSZ (bit 31) has no influence on the received data in the RXFIFO and POPR.

Here is my test program mainc.c:

#include "board.h"
#include "pin_mux.h"
#include "fsl_device_registers.h"
#include "fsl_clock_manager.h"
#include "fsl_interrupt_manager.h"
#include "fsl_debug_console.h"
#include <stdio.h>

/* define SPI1 registers */
#define SPI1MRC  0x4002D000
#define SPI1CTAR0  0x4002D00C
#define SPI1SR   0x4002D02C
#define SPI1RSER  0x4002D030
#define SPI1POPR  0x4002D038
/* define some bits in SPIx registers */
#define HALT     0x00000001
#define RXFIFO     0x00001000
#define CLR_TXF     0x00000800
#define CLR_RXF     0x00000400
#define RFDF     0x00020000
/* and some other needed defines */
#define GPIOAT      0x400ff00c
#define PTA11  (1<<11)
#define RXBUFSIZE 64
#define UIP unsigned int *

unsigned int *rxptr, rxcnt, rxval, rxbuf[RXBUFSIZE+2];

int main(void)
{
int i;
rxcnt = rxval = 0;
rxptr = rxbuf;
for (i=0; i++; i<RXBUFSIZE) rxbuf[i] = 0;

CLOCK_SYS_EnablePortClock(PORTA_IDX);
CLOCK_SYS_EnablePortClock(PORTB_IDX);
CLOCK_SYS_EnablePortClock(PORTC_IDX);
CLOCK_SYS_EnablePortClock(PORTD_IDX);
CLOCK_SYS_EnablePortClock(PORTE_IDX);

BOARD_ClockInit();
dbg_uart_init();
GPIO_DRV_Init(switchPins, ledPins);

configure_spi_pins(1);
CLOCK_SYS_EnableSpiClock(1);

*(UIP)SPI1MRC =  HALT;     // halt SP1 for any case
*(UIP)SPI1MRC |= RXFIFO|CLR_TXF|CLR_RXF;
*(UIP)SPI1SR =  0xFFFFFFFF;    // clr all bits
*(UIP)SPI1RSER = RFDF ;     // generate interrupt from RFDF
*(UIP)SPI1CTAR0 = 0xF8000000;   // frame32, inact.low, lead.edge

*(UIP)SPI1MRC = (*(UIP)SPI1MRC) & ~HALT; // start SPI1
INT_SYS_EnableIRQ(27);     // SPI1 vector = 43 = 16+27
INT_SYS_EnableIRQGlobal();


printf("\nTest SPI1 slave / PCM1804 master\r\n");

while(1) {
GPIO_SW_DELAY;
printf("\nrxcnt %08x   rxval %08x \r\n",rxcnt, rxval);
}
return 0;
}

void SPI1_IRQHandler(void) {
*(UIP)GPIOAT = PTA11;     // toggle test port (TGL on scope)
rxval= *(UIP)SPI1POPR;     // get received 32bit word
(*(UIP)SPI1SR) |= RFDF;     // clr RFDF
rxcnt++;
*(rxptr++)= rxval;      // store in rxbuf
if (rxptr-rxbuf>RXBUFSIZE) rxptr= rxbuf; // circular buffer
}

/*EOF*/

As you see, SPI1CTAR0 = 0xF8000000 - so frame= 32-bit, inact.low, lead.edge

but despite this setting I get two 16 bit frames (signal TGL below is toggled on each SPI1 Interrupt)

m11s.jpg

Scope screen shot shows a data frame starting with 0xfb.... - in the rxbuf we see high words with 0xfb... and low words with low byte equal to zero as the PCM1804 sends only 24 conversion bits and 8 zeros:

rxbuf.JPG

Ad 3)

Of course I've downloaded K60P144M100SF2RM.pdf also - in other case I couldn't report the  problem in point 2 !

All downloads were done from the NXP page.

But the best comes now - I've just downloaded K60P144M100SF2V2RM.pdf from NXP - link:

http://cache.nxp.com/files/32bit/doc/ref_manual/K60P144M100SF2V2RM.pdf?fpsp=1&WT_TYPE=Reference Manuals&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation&fileExt=.pdf

This time it is 20.5MB big !! - despite that you see:

k1.JPG

So I have now 3 Versions:

      14.229KB - downloaded 2014-03-05

      13.853KB - downloaded 2016-02-10

      20.502KB - downloaded 2016-03-31

When you open these files in an editor, you see that the content is different - one can only hope that the pdf view / printout will be the same - but nobody can check it page by page...

best regards

Piotr

PS 1

The above experience and other points e.g. mentioned in

Comments on TWR-K60D100, K60 and KSDK-1.3.0 documentation

or

Kinetis SDK v.1.3 API Reference Manual Rev.0 - the worst documentation I've ever seen !!! 

are not the best publicity for Kinetis ...

PS 2

a) why it is not posssible to attach a file to a posting (e.g. my main.c) ??

b) why the automatical correction in the Editor here changes very often the first letterts to capitals ??

0 Kudos

247 Views
egoodii
Senior Contributor III

Does it make a difference to properly load PUSHR prior to each data reception?  I also notice you disable the RXFIFO, but NOT the TXFIFO -- seems odd.

0 Kudos

247 Views
piotrfyda
Contributor I

Hello,

Why should I load PUSHR when I do only receive as slave ???

Same concerning TXFIFO ! (transmitter is disabled)

There is no danger I get an overrun (no load in the test program at all) - so RXFIFO is disabled for easier handling.

But the same problem is with RXFIFO enabled !

kind regards

Piotr

0 Kudos

247 Views
egoodii
Senior Contributor III

SPI is INHERENTLY bidirectional, and SOMETHING will TX for each RX.  I don't KNOW if giving PUSHR something 'valid' will affect receive data grouping, or even how the hardware handles a '32 bit length' callout from the 16-bit PUSHR -- but it seems worth testing.  Try pushing two words before each RX.  It is interesting to note that the K64 manual talks about PUSHR being full 32bits in 'slave' mode.

You mention a 'V2' reference manual -- are you running V2 chips? (No 'Z' in the P/N)

Have you tried running with CONT_SCKE?

What happens if you run a 24-bit length?

0 Kudos

247 Views
piotrfyda
Contributor I

1)

You write:

I don't KNOW if giving PUSHR something 'valid' will affect receive data grouping, or even how the hardware handles a '32 bit length' callout from the 16-bit PUSHR -- but it seems worth testing

Do you mean I should test it ??? NXP sells the stuff, so it should know how it works !!

2)

The answer to your question " What happens if you run a 24-bit length?" is clear - I've told already:

"the highest bit of FMSZ (bit 31 of SPI1CTAR0) has no influence on the received data in the RXFIFO and POPR"

and I receive for each /CS and 32 clocks two frames with 8 bits only.

3)

In the e-mail I've received there are no lines:

You mention a 'V2' reference manual -- are you running V2 chips? (No 'Z' in the P/N)

Have you tried running with CONT_SCKE?

which are visible on the https://community.freescale.com/message/.

Here the answers:

Yes, I run V2 chip

Yes, no change - for me this bit seems to be only for master mode

regards

Piotr

0 Kudos