How's this problem? Have you already found a solution to this?
JBRenesasRulz Forum Moderator
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:
In reply to tenballs:
0x60000000 (BSP_PRV_QSPI_DEVICE_PHYSICAL_ADDRESS) is the base address of the QSPI ROM Window in the Cortex-M4 address map :-
@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?
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?
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?