• 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

Reply
  • 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

Children
Related
Terms of service