AnsweredAssumed Answered

BF523 SPI EMUEXCPT

Question asked by docsassy on Oct 2, 2014
Latest reply on Mar 9, 2015 by jobo23

Hi,

 

On our custom DSP board we're running an M25P32 flash chip of which we're using a few blocks as NVM.  We have a strange issue that when we erase/write a block we're getting an EMUEXCPT crash.

 

We're not running the SPI in interrrupt mode so we're simply polling the status register for the RXS flag to determine when the next byte can be sent.  We've narrowed down the issue to the write command and in paticular the while loop whilst waiting for the RXS flag.  I've included the code below.  We're using VDSP++ with VDK.

 

static SPI_API_STATUS do_write(UINT32 length)

{

  UINT8  inchar;    // Used to store the read byte.

  UINT8 db;

 

  REG_CLEAR(*pSPI_CTL,SPE);  // Disable SPI

  SSYNC;

  REG_WRITE(*pSPI_BAUD, spi_config[transaction.handle].reg_baud);

  SSYNC;

  REG_WRITE(*pSPI_CTL, MSTR | EMISO | TDBR_CORE | spi_config[transaction.handle].reg_ctl);

  SSYNC;

  REG_SET(*pSPI_CTL, SPE);  // Enable SPI

  SSYNC;

  /* If there are any sticky bits set, clear them. */

  REG_WRITE(*pSPI_STAT, 0xff);

  SSYNC;

  while ( (length) && (transaction.txlen) )

  {

  db = *(transaction.txdata);

 

    REG_WRITE(*pSPI_TDBR,db);

    SSYNC;

  transaction.txdata++;

 

    // Wait for the response to be received

    while(!(*pSPI_STAT & (RXS | RBSY)));

    

    // Save response

    inchar = *pSPI_RDBR;  // Note we don't do anything with inchar when writing.

    length--;

    transaction.txlen--;

  }

  REG_CLEAR(*pSPI_CTL,SPE);  // Disable SPI

  SSYNC;

  return SPI_SUCCESS;

}

 

We've tried quite a few things such as switching out the wait flag to TXS which whilst it sped up the wait loop so the issue happened less frequently, it still happens without fail.  We've also tried disabbling all interrrupts around the SPI transactions, which also includes a mutex lock, but again this achieved nothing.

 

What are we doing to cause this issue?  Would changing the driver to be interrupt driven instead fix this issue or simply mask it?

 

cheers,

 

Julian

Outcomes