I am using a Teensy3.5 (MK64FX512VMD12 based).
Having made some progress experimenting with DMA, I am trying to generate a single bit datastream using SPI and DMA. My requirement is I want this stream to be totally continuous at a 1MHz rate with no gaps.
I have written code to use DMA to stream from a 8-bit array, by using DMA to re-fill the PUSHR SPI register.
The code is working to an extent, except for the problem that at the end of every 8 bits written to PUSHR is a single '1' bit, sort of like a stop bit. So for each byte transferred via DMA I see 9 bits and 9 corresponding clocks.
I am aware of the CONT bit in the PUSHR register and I am setting this to '1' (I think - perhaps not!).
The DMA transfer however is 8-bit. I am hoping that the earlier 32 bit write to PUSHR is held and the DMA write only overwrites the lower 8-bits, but I am not sure that this is happening. With CONT zero you see the behaviour I observe on the scope.
In the reference manual I see the cryptic text "Specifies data to be transferred to the TX FIFO. An 8- or 16-bit write access transfers all 32 bits to the TX FIFO". I do not know how to interpret this.
I tried reading back the register having written to all 32 bits, but I get a strange value.
SPI1_PUSHR = 0x80005555;
SPI1_PUSHR = 0x80005555;
SPI1_PUSHR = 0x80005555;
SPI1_PUSHR = 0x80005555;
SPI1_PUSHR = 0x80005555;
uint32_t cxn = SPI1_PUSHR;
sprintf(sbuf," SPI1_PUSHR = %08lx",cxn); Serial.println(sbuf);
This is my attempt to initialise the CONT bit to '1', hoping it will remain set to '1' during the later DMA 8-bit transfer of the 8-bit value to be transmitted.
The value printed out is "000000aa". Obviously not the result I expected.
I do not know whether to use CONT in DMA mode you are forced to do 32-bit transfers?
I operate in Master mode.
#define SPI1_PUSHR (KINETISK_SPI1.PUSHR) // DSPI PUSH TX FIFO Register In Master Mode
#define KINETISK_SPI1 (*(KINETISK_SPI_t *)0x4002D000)
typedef struct {
volatile uint32_t MCR; // 0
volatile uint32_t unused1;// 4
volatile uint32_t TCR; // 8
volatile uint32_t CTAR0; // c
volatile uint32_t CTAR1; // 10
volatile uint32_t CTAR2; // 14
volatile uint32_t CTAR3; // 18
volatile uint32_t CTAR4; // 1c
volatile uint32_t CTAR5; // 20
volatile uint32_t CTAR6; // 24
volatile uint32_t CTAR7; // 28
volatile uint32_t SR; // 2c
volatile uint32_t RSER; // 30
volatile uint32_t PUSHR; // 34
volatile uint32_t POPR; // 38
volatile uint32_t TXFR[16]; // 3c
volatile uint32_t RXFR[16]; // 7c
} KINETISK_SPI_t;
TBH is seems a strange choice to mix this mode bit with the transmit buffer register.
