![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2016\/03\/01-embwiz.png\")
<\/a><\/li>\n<\/a><\/li>\n<\/a><\/li>\n<\/a><\/li>\n<\/a><\/li>\n<\/a><\/li>\n<\/a><\/li>\n- \n
- QSPI_EnableMemoryMappedMode()<\/strong> is the main function that maps the QSPI FLASH to address 0x90000000<\/li>\n
- Functions like QSPI_DummyCyclesCfg()<\/strong> and QSPI_WriteEnable()<\/strong> configure the external FLASH memory chip by writing chip-specific commands<\/li>\n
- Functions like HAP_QSPI_Transmit()<\/strong> are provided by the STM32 HAL library and are responsible for delivering the commands to the chip
![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2016\/03\/08-calls.png\")
<\/a><\/li>\n<\/ul>\n<\/li>\n- Move the code responsible for the blinking LED to a function called FunctionInQSPIFLASH() and edit the main source file to call the QSPI_EnableMemoryMappedMode()<\/strong> function before calling the LED blinking function:\n
QSPI_HandleTypeDef QSPIHandle;\r\n\r\nint main(void)\r\n{\r\n HAL_Init();\r\n \u00a0 QSPI_EnableMemoryMappedMode(&QSPIHandle, 0, 0x10000);\r\n FunctionInQSPIFLASH();\r\n}<\/pre>\n![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2016\/03\/10-mem.png\")
<\/a>Note that we have NOT<\/strong> placed the function to the QSPI FLASH yet, so the function will reside in normal FLASH memory. Build the project and note how the FunctionInQSPIFLASH got placed in the regular 0x0800xxxx<\/strong> range.<\/li>\n- Set a breakpoint at the call to FunctionInQSPIFLASH()<\/strong> and hit F5 to start debugging. Once the breakpoint is hit verify that the address of FunctionInQSPIFLASH<\/strong> is still inside the main FLASH area (0x08xxxxxx) and that the memory at address 0x90000000 is readable (it should show contents of the actual QSPI FLASH memory programmed by any previous QSPI-based program that ran on the board):
![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2016\/03\/mems-1.png\")
<\/a><\/li>\n- Now we will actually configure the project to use the QSPI memory. Open VisualGDB Project Properties and go to the Additional Memories page. Add a new memory called QSPI at address 0x90000000. In this example we will limit the memory size to 64K (0x10000), however you can specify the actual QSPI FLASH chip size as well:
![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2016\/03\/11-external.png\")
<\/a>Note that the “Additional Memories” feature is supported on VisualGDB Custom Edition and higher.<\/li>\n- Press OK to apply the settings. Note how VisualGDB has created a copy of the linker script file and inserted the memory definition lines there. When you edit the external memory settings, VisualGDB will replace the lines between “— begin generated xxx —” and “— end generated xxx –” lines, preserving the rest of the linker script:\u00a0 \u00a0
![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2016\/03\/12-lds.png\")
<\/a><\/li>\n- VisualGDB as also added an ExtraMemories.h<\/strong> file that defines macros for placing your functions and variables to the external memories:
![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2016\/03\/13-extramem.png\")
<\/a><\/li>\n- Include the “ExtraMemories.h” file from your main file and add the QSPI_TEXT macro to the declaration of FunctionInQSPIFLASH(). Then build your project:
![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2016\/03\/14-qspi.png\")
<\/a>Note how the used FLASH size has reduced and the FunctionInQSPIFLASH<\/strong> got moved to a new memory called QSPI<\/strong>.<\/li>\n- If you try to start debugging your project now, you will see that although the main FLASH memory expects the FunctionInQSPIFLASH() to be at address 0x90000000, the actual data at this address is different. This happens because OpenOCD does not know how to program the QSPI FLASH. This can be fixed by downloading<\/a> the QSPI FLASH plugin for OpenOCD, or building it as described in this tutorial<\/a> and adding the following command to the OpenOCD command line:\n
-c \"flash bank qspi plugin 0x90000000 0 0 0 0 $(ProjectDir.forwardslashes)\/stm32f7disco_qspi.elf\"<\/pre>\n
![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2016\/03\/15-cmd-1.png\")
<\/a><\/li>\n- Now you can simply press F5 to automatically program the chip and begin debugging it. As of September 2023, OpenOCD now properly supports setting hardware breakpoints in QSPI memories, so you can set a breakpoint in FunctionInQSPIFLASH()<\/strong> and wait for it to hit:
![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2016\/03\/16-pc.png\")
<\/a><\/li>\n- Now we will show how to place a pre-initialized array into the QSPI FLASH memory without increasing the utilization of the normal FLASH. Declare a static const array with the QSPI_DATA<\/strong> macro and change FunctionInQSPIFLASH()<\/strong> to use it:\n
static const int QSPI_DATA LargeArray[] = { 100, 200, 300, 400, 500, 600 };<\/pre>\n![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2016\/03\/qspidelta.png\")
<\/a>Build your program and observe how the QSPI utilization has increased while the FLASH and RAM utilizations were unchanged.<\/li>\n- You can launch debugging with F5 (don’t forget to re-program the QSPI memory using the ST-Link tool unless you have automated this using the OpenOCD plugin) and see that LargeArray<\/strong> got placed to QSPI FLASH after the FunctionInQSPIFLASH<\/strong>:
![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2016\/03\/17-data.png\")
<\/a><\/li>\n- If you are using VisualGDB Custom Edition 6.0 or later, you can set tracepoints instead of breakpoints to quickly record what the program is doing without actually stopping it. Try enabling software tracing as shown here<\/a> and setting a tracepoints on the calls to HAL_Delay()<\/strong> tracing the values of TickCount<\/strong> and i<\/strong>. If you run the program now, you will immediately see how these lines get executed in real time:
![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2016\/03\/18-trace.png\")
<\/a><\/li>\n- You can use the tracepoints\/trace data windows to review each recorded invocation of the HAL_Delay()<\/strong> line, or create a trace data view to quickly visualize how the variable values changed over time:
![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2016\/03\/19-graph.png\")
<\/a><\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"This tutorial shows how to add support for an external off-chip memory, such as a NOR FLASH to a VisualGDB<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[27],"tags":[53,120,61],"_links":{"self":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts\/1568"}],"collection":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/comments?post=1568"}],"version-history":[{"count":7,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts\/1568\/revisions"}],"predecessor-version":[{"id":8344,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts\/1568\/revisions\/8344"}],"wp:attachment":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/media?parent=1568"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/categories?post=1568"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/tags?post=1568"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- Functions like QSPI_DummyCyclesCfg()<\/strong> and QSPI_WriteEnable()<\/strong> configure the external FLASH memory chip by writing chip-specific commands<\/li>\n