This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Concurrently using XIP and QSPI to read back data from external flash

Dear Nordic,

I have a 4MB external flash on my board, I've successfully run the code on it by using XIP. However, I got stuck when I was trying to read back data from external flash. The following picture has the call stack trace. It's a failure of NRFX_ASSERT.

Some more details:

Using nrfx driver both in bootloader and application is not a good idea, because the driver status is stored in the different RAM area. I add a fake initialization function for QSPI to keep the peripheral status consistent. Do you have any better ideas?

Best Regards,

Eugene

Parents
  • Hi Hung,

    I think the assertion failure is caused by the flag `wipwait`, you can see from the trace stack and refer to the nrfx source code,`wipwait` is set to false in `nrfx_qspi_mem_busy_check`.

     

    Hung Bui said:
    If you don't do XIP and only do a read out the data in QSPI do you see an error ? 

    No, when the same code runs in the internal flash, everything works fine. 

    Hung Bui said:
    Regarding your question about bootloader and application both use nrfx. Could you give some more information of the issue ? My understanding is that since the driver status is remains in RAM , if it's not been reinitialize in the application properly we may have an issue ?  

    nrfx driver is compiled twice for bootloader and application, that means we have duplicated .data segment and .bss segment for nrfx driver. When initializing nrfx driver in the bootloader, it just modifies .data(bootloader) and .bss(bootloader), it has nothing to do with .data(application) and .bss(application). After jumping to the application from the bootloader, we call nrfx again, and it finds the driver is not initialized, so it repeats the initialization work again, for nrfx_qspi, if you initialize it again, XIP may not work properly

    Best Regards,

    Eugene

Reply
  • Hi Hung,

    I think the assertion failure is caused by the flag `wipwait`, you can see from the trace stack and refer to the nrfx source code,`wipwait` is set to false in `nrfx_qspi_mem_busy_check`.

     

    Hung Bui said:
    If you don't do XIP and only do a read out the data in QSPI do you see an error ? 

    No, when the same code runs in the internal flash, everything works fine. 

    Hung Bui said:
    Regarding your question about bootloader and application both use nrfx. Could you give some more information of the issue ? My understanding is that since the driver status is remains in RAM , if it's not been reinitialize in the application properly we may have an issue ?  

    nrfx driver is compiled twice for bootloader and application, that means we have duplicated .data segment and .bss segment for nrfx driver. When initializing nrfx driver in the bootloader, it just modifies .data(bootloader) and .bss(bootloader), it has nothing to do with .data(application) and .bss(application). After jumping to the application from the bootloader, we call nrfx again, and it finds the driver is not initialized, so it repeats the initialization work again, for nrfx_qspi, if you initialize it again, XIP may not work properly

    Best Regards,

    Eugene

Children
No Data
Related