MCUBOOT / Application - problem with SPI interface

gorakk — Mon, 26 Aug 2019 19:53:28 GMT

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

MCUBOOT 2.7.0

Re: MCUBOOT / Application - problem with SPI interface

jingpan — Tue, 27 Aug 2019 07:27:21 GMT

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.

Regards,

Jing

topic MCUBOOT / Application - problem with SPI interface in MCU Bootloader

MCUBOOT / Application - problem with SPI interface

Re: MCUBOOT / Application - problem with SPI interface