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)
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:
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:
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 ??
