MCUBOOT / Application - problem with SPI interface

Showing results for 
Show  only  | Search instead for 
Did you mean: 

MCUBOOT / Application - problem with SPI interface

Contributor IV

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 )  // don't flush the TX FIFO‍

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:

 * @brief Flushes the DSPI FIFOs.
 * @param base DSPI peripheral address.
 * @param flushTxFifo Flushes (true) the Tx FIFO; Otherwise, does not flush (false) the Tx FIFO
 * @param flushRxFifo Flushes (true) the Rx FIFO; Otherwise, does not flush (false) the Rx FIFO
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


0 Kudos
1 Reply

NXP TechSupport
NXP TechSupport

Hi Allen,

1. What do you mean of crash, hardfault? The only situation I can image is the SPI peripheral clock isn't set.

2. No, it couldn't. These application is base on the driver. If the SPI is initialized well, is won't cause crash.



0 Kudos