Combined XIP and FileX on QSPI flash

While developing a GUI application for the S5D9 controller interfacing a 7 inch display, I ran into something which apparently isn't as straight-forward as I expected. I was wondering if anyone could point me into the right direction to implement the following.

Using the PK-S5D9 promotion kit as an example, I would like to have the QSPI NOR flash chip divided into two sections. One half of the chip will be used for file I/O using FileX and the other half will be used to store image data for the user interface (XIP). I realize that these two approaches require different operation modes for the QSPI peripheral, but I cannot find anything on how and when to switch these modes. Can they coexist at all?

Regards,

Joost Heijne

  • Hello Joost,

    As far as I know QSPI flash goes out of XIP mode when QSPI driver open() is called and goes back into XIP mode when QSPI driver close() is called.


    So, basycally, you need to:

    1. Protect usage of QSPI NOR flash by a mutex:
    get it before you're going to draw something, draw, put it back
    get it before you start working with FileX, open media, do what you need, close media, put it back

    2. Allocate half of the chip for FileX usage - with SSP 1.7.5 it is possible if you use FileX on top of LevelX - there are parameters for it now that allows you to specify LevelX partition offset and size on the QSPI flash.


    If you would use LevelX then there is probably also a bug workaround you need - after every close of FileX media (fx_media_close()) you need to add:

    ((sf_block_media_on_lx_nor_cfg_t*)(<fx_media_instance_cfg>.p_lower_lvl_block_media->p_cfg->p_extend))->close();

    Without it underlying drivers of FileX would not be closed and flash would not return into XIP mode - but I'm not sure about that, so you have to check it for yourself.

    Also, even though I'm sure that it is possible to divide flash as you described, the switching process may be relatively slow and I'm not sure if it is suitable for drawing of user interface. I suggest testing.

    Best regards,
    Eighth

  • In reply to Eighth:

    Hi Eighth,

    Thanks for the clear explanation. I will try this early next week an share my findings.

    Best regards,

    Joost
  • Hello Joost,

    Could you please tell us if you succeeded in solving your issue?

    Kind regards,
  • In reply to Sergey Sokol:

    Sorry, I haven't been able to perform the tests due to other priorities. I might be able to do it tomorrow.

    Joost
  • In reply to Sergey Sokol:

    Hi, colleague of Joost here,

    I'm not a 100% sure yet but it seems we got it to work by doing 2 things.
    - Completely erased the qspi flash
    - Moved the levelx partition to the start of the qspi flash. I don't have the time further check but there seems to be a bug somewhere before calling sf_el_lx_nor_validate_read_write_address (this is called in SF_EL_LX_NOR_BlockErase). This function returns an error because it seems the levelx partition offset isn't added to block_address argument of the call (while inside the sf_el_lx_nor_validate_read_write_address the start address IS calculated with the offset). So the validation fails because the block_address without the offset is indeed outside of the levelx erea.

    I sadly don't have time to further investigate, so I leave it with you. I'd love to hear your findings if you or your team do any more investigating.

    Kind regards,
    Rene