• State Not Answered
  • Replies 7 replies
  • Subscribers 25 subscribers
  • Views 200 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 290193
Options

Interrupt Missing In When QSPI Is Configured In Interrupt Mode

user89683

Hello,

Aim : To write and read x bytes from the QSPI interfaced external PSRAM(APS6404L-3SQR) using the nRf52840.

Configuration : Following is the configuration of the QSPI

Protocol layer interface configuration
Execute in place operation : OFF
Interrupt Priority : 6
Read and Write Opcode : 4 Input/Output
Addressing Mode : 24 Bit
Deep Power-Down Mode: OFF(false)

Physical layer interface configuration
QSPI Frequency : 32MHz/1
SCLK Delay : 1
SPI Mode : 0
Deep Power-Down Mode: OFF(false)

Operation : write/read the PSRAM and wait for the ready interrupt

Problem : We observed that sometimes the interrupt never gets generated.
Following  are the functions for the read and write operation

Please let us know why we are facing this condition?

/*
* FUNCTION NAME: QspiEvtHandler
* PARAMETER    :  
* ACTION       : Handler for QSPI, event is generated once qspi finished read/write operation
*/
void QspiEvtHandler(nrf_drv_qspi_evt_t event, void * p_context)
{
    UNUSED_PARAMETER(event);
    UNUSED_PARAMETER(p_context);
    qspi_finished = true;
}


/*
* FUNCTION NAME: PsramRead
* PARAMETER    : index: PSRAM no,  address: PSRAM address, size: buf size
                 *data_ptr: data ptr of read buf
                 retun error   
* ACTION       : Read from selected psram bank
*/
uint32_t PsramRead(uint8_t index, uint32_t addr, uint16_t size, uint8_t *data_ptr) 
{
    ret_code = nrf_drv_qspi_read(data_ptr, size, addr);
    APP_ERROR_CHECK(ret_code);
    while (qspi_finished == false);
}


/*
* FUNCTION NAME: PsramWrite
* PARAMETER    : index: PSRAM no,  address: PSRAM address, size: buf size
                 *data_ptr: data ptr of write buf
                 retun error   
* ACTION       : Write into selected psram bank
*/
uint32_t PsramWrite(uint8_t index, uint32_t addr, uint16_t size, uint8_t *data_ptr) 
{
    ret_code = nrf_drv_qspi_write(data_ptr, size, addr);
    APP_ERROR_CHECK(ret_code);
    while (qspi_finished == false);
}

Parents
  • 0

    Hi,

    Which SDK and version do you use?

    If you use nRF5, you can take a look at qspi in the documentation. You could also take a look at the sample in \examples\peripheral\qspi.
    You could try changing interrupt priority value. More information about interrupt priorities is available in this discussion.

    Best regards,
    Dejan

  • 0 in reply to user111786

    Hello Dejans,

    We are using SDK V15.3.0, softdevice S140(In disabled state)


    Following are more details on the active peripherals, their functions and priority levels while the PSRAM read/write action is performed

    1. General purpose timer Instance 1 running at frequency of 1Khz with priority level at 6
    2. RTC timer sampling 5 channel enabled internal SAADC at frequency of 1Khz with both the SAADC and RTC priority levels at 6
    3. UART at the baud rate of 115200 with priority level at 6
    4. Application timers with priority level at 6
    5. SPI interfaced external ADC collecting sensor data using PPI 100kSamples/Sec, the SPI priority level at 2
    6. QSPI at priority level 6


    Referring to our PsramRead and PsramWrite functions, the control waits in the while loop until the interrupt indicates free state of the QSPI for a maximum of 10sec(the WatchDog triggers after 10 sec)
    We believe that the interrupts in the cortex M4 controllers may occur in a delayed form if configured at a lower priority but never be missed, please let us know if this understanding is valid for the issue that we are facing?

    Thanks and Regards,
    Sakib

  • 0 in reply to user89683

    Hi,

    With regard to your question about interrupts not being generated, SoftDevice determines interrupt priority levels in such  way that most critical interrupts have lowest possible interrupt levels.
    In the same link you can read that it is expected for interrupts to be postponed or preemted which can lead to a longer perceived interrupt latency and execution time.

    Best regards,
    Dejan

  • 0 in reply to user111786

    Hello Dejans,

    Thank you for the information, Following are our observation while debugging the issue

    The interrupt is never generated if the number of bytes to be written is lesser than 4 (i.e 1, 2, 3)
    i.e In the "p_reg->WRITE.CNT = length" the length is lesser than 4

    Please note that the write is successful for all the values greater than equal to 4.

    Please let us know if this is the expected working of the QSPI driver?

    Thanks,
    Sakib

  • 0 in reply to user89683

    Hi,

    WRITE.CNT is transfer length in bytes. The length must be multiple of 4 bytes.

    Best regards,
    Dejan

Reply Children
Related
Terms of service