AnsweredAssumed Answered

Baremetal SPI example for K64

Question asked by Drew Kelley on Feb 26, 2015
Latest reply on Sep 3, 2015 by Mark Butcher

Does anyone have a baremetal example for the SPI peripherals on the K64, ideally working in Master mode? Alternatively, a decent functional walkthrough would work too. The SPI documentation in the K64 Reference Manual leaves a lot to be desired. (Edit: To clarify, I'm using the TWR-K64F12M so the specific chip is the PK64FN1M0VMD12 - 144pin BGA)


Currently I'm running into trouble getting  transmission to occur. I've configured my SPI1 in the following manner:


  • Master Mode
  • Continuous SCK disabled
  • SPI configuration
  • Freeze disabled
  • Modified format disabled.
  • PCS Strobe Disabled
  • RX Fifo Overwrite enabled
  • PCS inactive high for all PCS pins.
  • Doze disabled
  • Module ENabled (MDIS cleared)
  • TX FIFO enabled (DIS_TXF cleared)
  • RX FIFIO enabled (DIS_RXF cleared)
  • Sample point, 0 cycles,
  • Halt disabled.


  • Double baud rate disabled
  • Frame size - 8 bits
  • SCK Inactive high
  • MSB first
  • Various timing prescalers to 1
  • Baud Prescaler  = 2
  • Timing scalers = 2
  • Baud Rate Scaler = 32 (Running a 60Mhz bus clock so this gives me a 975kHz SCK frequency)

(CTAR1 is unused)

After configuring the SPI and setting proper pin mux values, I'm trying to push 2 bytes out over the bus to a daq chip I've got just to read the device ID registers. I create a 2-byte buffer, and pass it to my SPI_Push_Bytes function that loops through the buffer for a specified number of bytes, builds the command value from specified pcs and ctar selection settings (both 0 in this case), and appends the current byte before writing the PUSHR register with the new value. When I put a breakpoint after that write I can clearly see the PUSHR and TXFR0 values update for the first byte. When the function loops back around to the second byte, it again formats the PUSHR value correctly, but seems to be overwriting the TXFR0 value and nothing is transmitting.


I'm configuring the command for that last byte to include the "End of Queue" trigger and then am waiting for the SR[EOQF] flag to get set but it never does, so clearly nothing is happening at all.  Is there a step I'm missing somewhere? Some flag that needs to be set or cleared before the transmitter becomes active? I've enabled the clock gate from the SIM and have gone through the SPI register documentation multiple times but can't seem to find what I'm missing. As far as I'm aware, everything is configured properly to start the transfers according to pg 1470 in the reference manual:

  • SR[EOQF] is clear,
  • MCR[FRZ] is clear so debugging doesn't stop serial transfers, and
  • MCR[HALT] is clear so the device should be in the running state.


Any help would be appreciated.