I have system that is using a K22FN512 as a SPI slave to a K61 master.
The K61 is meant to communicate to the K22 through SPI - for normal operation and also for loading new application firmware into the K22.
What I am seeing is that if the application is loaded normally, without a bootloader, the K61 and K22 can communicate.
If the K22 application is loaded by the bootloader - the application call to:
DSPI_FlushFifo ( base, true, true )
within the DSPI_SlaveTransferNonBlocking() function will crash.
If I change DSPI_SlaveTransferNonBlocking() to use:
DSPI_FlushFifo ( base, false, true )
the K22 application will not crash - but it also doesn't respond to the master.
In this state the K22 is still able to receive data from the K61 but I don't see anything coming from the K22 (verified with an oscilloscope).
The DSPI_FlushFifo() function just sets a couple of bits in the MCR register:
static inline void DSPI_FlushFifo(SPI_Type *base, bool flushTxFifo, bool flushRxFifo)
{
base->MCR = (base->MCR & (~(SPI_MCR_CLR_TXF_MASK | SPI_MCR_CLR_RXF_MASK))) |
SPI_MCR_CLR_TXF((true == flushTxFifo ? 1U : 0U)) | SPI_MCR_CLR_RXF((true == flushRxFifo ? 1U : 0U));
}
1) Under what conditions could setting the CLR_TXF bit in the MCR register cause a problem?
2) Could the MCU bootloader be leaving the SPI peripheral in a state that DSPI_SlaveTransferNonBlocking() isn't expecting?
MCUXpresso IDE v11.0.0
SDK 2.6.0
MCUBOOT 2.7.0