SSP QSPI Driver for MT25QL256ABA1EW7 on S5D9

Dear all,

I'm on S5D9 SSP1.6.3.

I'm trying to modify bsp_qspi file drivers from the custom W25Q64FV, to my MT25QL256.

A lot of things go different, like chipID, sizes, but most of all I have different number and types of status registers and commands.

I am trying to port commands and settings from the datasheet but simply doesn't work reads always all 0x00 in the following structure :

typedef struct st_qspi_characteristics
{
uint8_t manufacturer_id; ///< Manufacturer ID
uint8_t memory_type; ///< Memory type
uint8_t memory_capacity; ///< Memory capacity
} qspi_characteristics;

Do you have any information where I can get a bsp_qspi SSP file for this particular Flash?

Changing by hand is taking me lot of time, also I have issues entering and exiting XIP mode, figuring out sector, subsector, bulk erase commands, etc..

 

Just wondered maybe there's one bsp_qspi driver already written for this MT25QL256.

www.micron.com/.../mt25ql256aba1ew7-0sit

 

Thanks for your help,

S

  • Good day, Rusty!

    Have you already figured this one out? I'm not quite sure if there's one bsp_qspi driver already written for this MT25QL256. You may refer to this document for further information: www.renesas.com/.../r11an0071eu0112-synergy-custom-bsp-creation.pdf

    Best Regards,

    Sai
    RenesasRulz Forum Moderator
    https://renesasrulz.com/
    https://academy.renesas.com/
    en-us.knowledgebase.renesas.com/
  • In reply to Sai:

    Morning Sai,
    thanks for your answer.

    Unfortunately I'm still stuck with it. Seems like not only the low level bsp_qspi has to be changed (this has been done porting from another bsp for S7 SK board) but also r_qspi module has to change in order to be able and communicate with the lower bsp level.

    SSP doesn't support development for MT25QL256 or other qspi flash memories?

    Thanks,
    S
  • In reply to Rusty:

    There are no Renesas Synergy boards that use the MT25QL256 QSPI memory, so there is no driver for that particular device from Renesas. The V3.x S7G2-DK and the v2.x S3A7-DK boards both use an older Micron QSPI flash memory device, N25Q256A, so there is a bsp_qspi.c file for the N25Q256A devices in the BSP for those 2 boards. . There is a migration guide from Micron for migrating from the N25Q family of devices to the MT25QL family of devices :- www.micron.com/.../tn2501_migrating_n25q_to_mt25ql.pdf

    I am aware of customers having used a various different QSPI devices from different suppliers, without having to change the r_qsi HAL driver.

    EDIT:- Fixed the link to the Micron document

  • In reply to Jeremy:

    Thanks for the info Jeremy.
    I will try to follow this migration guide and see if I can figure out how to use MT25Q memory.

    Cheers,
    S

  • In reply to Jeremy:

    Hi,
    We are facing a similar problem...
    The link mentioned above is not opening...
    Thank You
    Regards,
    Surojit
  • In reply to Surojit:

    Do a google search for tn2501_migrating_n25q_to_mt25ql

    The pdf should come up as the first result.
  • In reply to WarrenM:

    I have edited the link, it should now work.
  • In reply to WarrenM:

    Got it...
    Will follow and get back on this...
    Thank you.
  • In reply to Jeremy:

    Hi Jeremy,

    I'm doing some tests on my MT25QL256.

    We have done a custom bsp with bsp_qspi ported from an old N25/MX25.

    First time I was able to run the QSPI_HAL_MG_AP example project, successfully writing and reading back from flash.

    After that, refuses to work any further.

    I've notice that in the bsp_qspi init the device characteristics are not read, inspecting the registers seems like commands in the bsp_qspi_device_reset() are not written, and so goes ahead reading 0x00 for memory type, capacity and manufacturer ID.

       /* Reset the flash device */

       bsp_qspi_device_reset();

       /* Read the ID of the device. Confirm it is the correct device. */

       R_QSPI->SFMCOM                         = QSPI_COMMAND_READ_ID;  /* Write the command */

       n25_device_characteristics.manufacturer_id = R_QSPI->SFMCOM_b.SFMD; /* Read the manufacturer ID */

       n25_device_characteristics.memory_type     = R_QSPI->SFMCOM_b.SFMD; /* Read the memory type */

       n25_device_characteristics.memory_capacity = R_QSPI->SFMCOM_b.SFMD; /* Read the memory capacity */

       R_QSPI->SFMCMD_b.DCOM                  = 1U;                    /* Close the SPI bus cycle */

       if ((BSP_PRV_N25_QSPI_MANUFACTURER_ID != n25_device_characteristics.manufacturer_id) ||

           (BSP_PRV_N25_QSPI_MEMORY_TYPE != n25_device_characteristics.memory_type) ||

           (BSP_PRV_N25_QSPI_MEMORY_CAPACITY != n25_device_characteristics.memory_capacity))

       {

           n25_device_characteristics.manufacturer_id = 0U;

           n25_device_characteristics.memory_type     = 0U;

           n25_device_characteristics.memory_capacity = 0U;

           return;

       }

    I tried to change (increase) dummy clocks, delays, changed qspi length in the linker script to 0x1000 0000, slow down clockdiv (our PCLKA is 120 Mhz, tried down to DIV10).

    From the migration instructions you provided I can see very few differences, main reset/read/write/erase commands are the same. At the moment I can't even reset in the initialisation so I think I have some problems writing QSPI registers in the MCU (SFMCOM and CMD seem not responding).

    Please find a screenshot:

    Do you have any suggestions or things that may be worth to try?

    Thanks for your support,

    KR

  • In reply to Rusty:

    If you can't read the device ID from the external QSPI device, you have probably put the external QSPI device into a mode of operation that is not compatible with the mode you are trying to operate in when you do a reset. Did you program any of the non-volatile configuration registers?
  • In reply to Jeremy:

    Thanks for your answer.
    I'm not aware of that, all I have done is initialising and trying to reset through the normal sequence like every bsp_qspi init.
    Strange thing is that one time I was able to read and verify written data, then only another time, then not anymore.
    If non volatile has been written, is there a way to restore it?

    Seems that MCU side QSPI registers are not written/updated correctly (SFMCMD and SMFCOM).

    Thanks
  • In reply to Rusty:

    If you have set the DTR bit in the Non-volatile configuration register, then the QSPI peripheral will not be able to communicate with the QSPI flash device, as the QSPI peripheral does not support DTR mode.
  • In reply to Jeremy:

    Rusty,

    If the DTR bit has been set, you can recover your device by changing the QSPI I/O pins to GPIO and bitb banging the QSPI to clear the DTR mode by sending the appropriate Commands. Please see the following threads for more information:

    https://renesasrulz.com/synergy/f/synergy---forum/7361/qspi-flash-support/32158#32158

    http://renesasrulz.com/synergy/f/synergy---forum/9550/qspi-nor-flash---custom-s7g2-board/32214#32214

     

    -Gary

  • In reply to garyj:

    Thanks Gary for the hint.
    So if I put your piece of code in my bsp_qspi.c, shoud I launch ResetQSPI_NVM() after or before qspi_init()?
    Also, you are using dual mode (DQ0, DQ1) and not quad mode, is that correct?

    Cheers,
    S
  • In reply to garyj:

    That worked like a charm.
    Thanks so much for your help!

    Have a nice day,
    S