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

[yuting0501]

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

[Hung Bui]

Hi Eugene, 

Could you tell what's the assertion error code ? 

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

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 ?  

[yuting0501]

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

[Hung Bui]

Hi Eugene,

According to this case, it seems that when you execute code from XIP and access the external flash, you may have longer wait: https://devzone.nordicsemi.com/f/nordic-q-a/42259/qspi-behavior-while-executing-xip-and-accessing-data-not-mapped-to-xip

Could you try modify QSPI_DEF_WAIT_TIME_US to increase it a little bit, and check if the result is still failed ? 

[yuting0501]

It doesn't work for me, I increased  `QSPI_DEF_WAIT_TIME_US` to 1000. Did you ever try to divide an external flash into two parts? One part for the XIP code, another part for a file system or just flash operation.

I initialize nrfx_qspi In the bootloader to enable XIP, if I initialize nrfx_qspi in the application again, it won't execute any code and gets stuck. If I don't initialize nrfx_qspi in the application, it gets timeout issue as we're talking about.

[yuting0501]

Since Nordic has an example to run XIP code in the external flash, could you please help modify the demo to read/write external flash, then I can compare it with my application. Thank you!