SPIFI Status Polling

[lpcware]

Content originally posted in LPCWare by tdrazich on Sun Feb 07 08:19:19 MST 2016
I am working with the SPIFI peripheral on an LPC1857 and integrating with an RTOS. I am using the S25FL032P flash device, for data storage and executing from the MCU internal flash. When erasing and writing the flash device, I wanted to have the peripheral perform the polling of the WIP bit within the flash device so that the calling thread could be blocked (rather than spinning and polling) until the SPIFI interrupt occurs. I've used the POLL bit within the command register and it appears to work, but I've noticed that while the peripheral is polling the flash device, the SysTick interrupt does not occur. Once the peripheral polling completes, the SysTick resumes. I don't think it has anything in particular to do with the SysTick, that's just how I noticed that nothing else is happening while the SPIFI is polling the device. It behaves as though the CPU is being stalled until the polling completes.

Any explanation for why this happens? Does the SPIFI stall the CPU while it is polling a device?

[lpcware]

Content originally posted in LPCWare by tdrazich on Tue Feb 09 09:09:45 MST 2016
Mike,

Thanks for the reply. All of the code is executing from internal flash, even the SysTick handler. I've done a bit more testing and now confirmed the CPU stalling regardless of the SysTick handler. I've placed the code I am using below and shows a test "flag" that is set by the command issuing code and cleared by the SPIFI interrupt handler. The command issuing code never blocks as the CPU stalled immediately after the command was issued and released when the polling was completed. For an erase command, this can be a considerable amount of time, typically milliseconds.

static UINT32 flag = 0;

STATUS SPIFI_WaitStatus(SPIFI* spifi, const SPIFICMD* cmd, BYTE* devstat, BYTE mask, BYTE bitval, UINT32 timeout)
{
    STATUS status;
    BYTE stat;
    static UINT32 testcnt = 0;
    

    /* Acquire exclusive access to the SPIFI */
    status = MUTEX_Acquire(&spifi->mutex, timeout);
    if (status != SUCCESS) {
        return status;
    }
    
    
    THREAD_ClearSignal(CFG_DRIVERSIGNAL);
    
    /* Set a flag to see when the interrupt occurred */
    flag = 1;
    
    /* Enable the SPIFI interrupt */
    spifi->REG->STAT.BITS.INTRQ = 1;
    spifi->REG->CTRL.BITS.INTEN = 1;
    
    /* Issue the command (opcode=5, poll bit=1) */
    spifi->REG->CMD = (cmd->opcode << 24) |
                      (cmd->frame << 21) |
                      (cmd->field << 19) |
                      (cmd->intlen << 16) |
                      (1 << 14) |
                      (mask & 0x7) | ((bitval & 1) << 4);
    
    stat = spifi->REG->DATA8;
    
    
    /* Test if the interrupt has already occurred */
    if (flag == 0) {
        testcnt++;  /* The interrupt has already occurred, must have stalled prior */
    }

    if (devstat) {
        *devstat = stat;
    }
    
    /* Wait for the status register bit to be cleared (signaled by interrupt handler) */
    status = THREAD_WaitOne(CFG_DRIVERSIGNAL, timeout);
    
    spifi->REG->CTRL.BITS.INTEN = 0;
    MUTEX_Release(&spifi->mutex);
    
    if (status != SUCCESS) {
        return status;
    }
    
    
    return SUCCESS;
}

static void SPIFI_IRQ(IRQ irq)
{
    SPIFI* spifi;
    

    /* Clear the test flag to know when this occurred */
    flag = 0;


    spifi = mcu_spifi[0];
    
    /* Release any waiting threads */
    if (spifi->mutex.owner) {
        THREAD_Signal(spifi->mutex.owner, CFG_DRIVERSIGNAL);
    }
    
    spifi->REG->CTRL.BITS.INTEN = 0;
    spifi->REG->STAT.BITS.INTRQ = 1;
}

In the end, this isn't a show stopper. I can manually poll the status register in a loop. I've switched to that in the meantime. I believe that's how the NXP spifi library is implemented. I just thought it would be nice to block the calling thread for the entire time the flash device was busy and let the hardware do all the work.

-Tyler

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Tue Feb 09 02:53:56 MST 2016
Just a thought, is your systick handler also in the SPI flash space?
If so, code execution will be stalled until the flash programming has completed.
NB: Any code attempting to execute from SPI will be stalled.

I hope that I am not stating the bleedin obvious.

Cheers, Mike.