QSPI Flash SSP_ERR_UNSUPPORTED

I am developing an application on a S7G2 Custom board.
I need the QSPI Flash interface for using an external flash memory.
 
The microcontroller part number: R7FS7G27H3A01CFB
Ext. Flash part number: S25FL127SABMFI101
 
I am in process of creating the custom BSP for the custom board.
The problem I am facing is that,
g_qspi0.p_api->open(g_qspi0.p_ctrl, g_qspi0.p_cfg);
returns with SSP_ERR_UNSUPPORTED.
I have read through the following posts that are relevant.
 
Despite reading all of them, I don't see what all changes are required to get the QSPI Flash interface functional.
Any help is appreciated.
  • Hi WedaPashi,

    How's this problem? Have you already found a solution to this?

    JB
    RenesasRulz Forum Moderator

    https://renesasrulz.com/
    https://academy.renesas.com/
    https://en-us.knowledgebase.renesas.com/

  • In reply to JB:

    The QSPI HAL driver needs the BSP QSPI setup code to correctly set up the QSPI device. If the BSP code does not correctly set up the QSPI device then the QSPI HAL driver open function will fail.

    The call to QSPI HAL driver will fail with a return of SSP_ERR_UNSUPPORTED if the BSP QSPI setup has failed to read the manufacturer_id correctly :-

     

  • In reply to Jeremy:

    Hi Jeremy,

    I have tried debugging the code. I can see that none of the functions from bsp_qspi.c are called.
    For example,

    bsp_qspi_xip_mode(), bsp_qspi_init(), bsp_qspi_xip_enter(), bsp_qspi_xip_exit(), bsp_qspi_status_get(), bsp_qspi_config_get(), etc... these are never called. I guess that is where the problem is.

    I am actually working on a tight timeline here and I can see that the custom BSP generation process specifically when we add QSPI to it, itself is very complicated the first time around. I am not really in favor of manually setting up the r_qspi.c file to read_only and get around it. When I don't that I see 134 errors which I am not interested in fixing, because those are about some SSP_HEADER related.

    If I don't resolve this quickly, I may have to rely on big-banging the SPI and get the flash up.

  • In reply to WedaPashi:

    Hi WedaPashi,

    Your case is similar to the problem discussed in the following thread.
    Have you tried this?

    (2204) QSPI Flash support - Synergy - Forum - Renesas Synergy Platform - RenesasRulz
    renesasrulz.com/.../qspi-flash-support
  • In reply to tenballs:

    Thank you tenballs. I think the problem is with the BSP itself because I am looking at the QSPI lines using the oscilloscope and I see that they all have been pulled high and there is no change in that through open() API calls.
  • In reply to WedaPashi:

    An update: In process of modifying the qspi_bsp.c, managed to resolve the SSP_ERR_UNSUPPORTED issue. The problem was with some of the macros that needed changes. Secondly, the bsp_init() function would not call bsp_qspi_init() function. Added that part and the SSP_ERR_UNSUPPORTED issue disappeared. Open, PageProgram() and read() commands are successful, but data read has all 0xFF. I will spend time understanding the significance of BSP_PRV_QSPI_DEVICE_PHYSICAL_ADDRESS set to (0x60000000U).
  • In reply to WedaPashi:

    0x60000000 (BSP_PRV_QSPI_DEVICE_PHYSICAL_ADDRESS) is the base address of the QSPI ROM Window in the Cortex-M4 address map :-

     

  • In reply to WedaPashi:

    >Secondly, the bsp_init() function would not call bsp_qspi_init() function.
    What BSP are you based on?
    I checked my project which use BSP 1.7.0 for SK-S7G2, bsp_init() function calls bsp_qspi_init() function.
  • In reply to tenballs:

    : Thanks for responding. I generated the custom BSP, but did not add the bsp_qspi.c and bsp_qspi.h files in synergy/board/myboard directory. When I do that, the code doesn't compile, r_qspi.c reports a lot of missing macros. For example, BSP_PRV_QSPI_DEVICE_PHYSICAL_ADDRESS is undefined, despite of it it being there in bsp_qspi.h, and the paths are added in project settings as advised in the guide. I then moved bsp_qspi.g into a separate directory under src where all other module sources are and added the header include for bsp_qspi.h in r_qspi.c and set the file to read-only. The code compiled with no errors. And, some changes (manufacturer id, capacity and memory type) in the macros as per what the flash datasheet says, resulted in SSP_SUCCESS to all qspi calls.

    What I am looking into now is, why the read() calls always return all 0xFF. It must be something with the configuration itself. Any thoughts?
  • In reply to Jeremy:

    @Jeremy: Thanks for responding. I generated the custom BSP, but did not add the bsp_qspi.c and bsp_qspi.h files in synergy/board/myboard directory. When I do that, the code doesn't compile, r_qspi.c reports a lot of missing macros. For example, BSP_PRV_QSPI_DEVICE_PHYSICAL_ADDRESS is undefined, despite of it being there in bsp_qspi.h, and the paths are added in project settings as advised in the guide. I then moved bsp_qspi.c into a separate directory under src where all other module sources are and added the header include for bsp_qspi.h in r_qspi.c and set the file to read-only. The code compiled with no errors. And, some changes (manufacturer id, capacity and memory type) in the macros as per what the flash datasheet says, resulted in SSP_SUCCESS to all qspi calls.

    What I am looking into now is, why the read() calls always return all 0xFF.

    I looked into the memory map you have shared (I should have looked that up in datasheet already, thanks!) the QSPI ROM window is 64 MB. The external flash chip we are using is 128 Mbit (16 MB). What do I change in configuration apart from manufacturer id, capacity and memory type macro?

    It must be something with the configuration itself. Any thoughts?

  • In reply to WedaPashi:

    If you look at an existing board bsp, then bsp_qspi.h is included via the file bsp.h. E.g. for the S5D9-PK board in the directory synergy\board\s5d9_pk\bsp.h :-

    #include "bsp_init.h"
    #include "bsp_qspi.h"
    #include "bsp_leds.h"
    #include "bsp_ethernet_phy.h"

    To be able to use the full 128MB of you QSPI device, you will need to use 4 byte addressing in the QSPI peripheral (most of the example BSP's only use 3 byte addressing), and you will only have access to 64MB at a time because of the 64MB QSPI window. to change which 64MB is accessible you will needto use the QSPI HAL driver R_QSPI_BankSelect() API.

    I would suggest you disable XIP mode initially, and just get ROM access mode to work reliably so that the CPU and the R_QSPI_Read() command can read the data in the QSPI device. If you are only ever reading back 0xFF, then I would suspect the QSPI device is not configured correctly, and not responding to the commands sent to it, for a read.
  • In reply to Jeremy:

     : Hi, s25fl127s is 128 Mb (16 MB) and not 128 MB. Am I still going to have to use 4-byte addressing? Link to datasheet of the flash part: S25FL127S 128 Mbit (16 Mbyte) 3.0V SPI Flash Memory

    I have attached r_qspi.c, bsp_qspi.c and bsp_qspi.h for your reference. Is there anything missing from initialization?

     Files.zip

  • In reply to WedaPashi:

    No, for 16MB (128Mb) you only need 3 byte addressing.
  • In reply to Jeremy:

     : Did you get a chance to look at the code I have shared? I am in process of understanding how to correctly initialize the flash.

    I have added a Memory view at 0x60000000 when I debug the code. After open() is called, I can see all values starting at 0x60000000 become 0xFF. Those values remain 0xFF even after Page Program API is called. Will the Memory view be able to display the newly written values after Page Program?

  • In reply to WedaPashi:

    Did you set up the QSPI pins correctly in the pin configurator? Yes, the memory view will be able to display the contents of the QSPI device, as long as the QSPI peripheral has been initialised, and the QSPI peripheral is in ROM access mode (i.e. the QSPI memory contents will not be displayed correctly when the processor has been reset and is the the reset entry point of the program). If the JLink debugger has downloaded and data into the QSPI flash device, then the JLink DLL will cache the areas it has downloaded, so if you attempt to update them from your code, the update will not be shown in the memory window, the caching can be turned off in the .jlink file in the root of the e2studio project :-

    [FLASH]
    CacheExcludeSize = 0x00
    CacheExcludeAddr = 0x00
    AllowCaching = 1