Hi there,
well, this is a really interesting question and since our latest release, this is handleable with a build-in solution. The already mentioned function EwRegisterFlashAreaReader() requires a so called external flash reader, which manages the data exchange between a non addressable memory and Embedded Wizard. Thereby it doesn't matter whether the external memory is a NAND flash or for example a SD card. Both are not directly addressable and bitmap and font resources on those can be made accessible by registering an external external flash reader.
Normally a linker only accept to link data into sections which are defined by the linker script. Otherwise the data cannot be found, but data on an SD card or NAND flash doesn't have an address. To solve that problem, we have to have a memory area within the linker script which gives the data an address, even when the data won’t be really stored at this address.
As next the make process has to take into account to separate the data before the flash tool could try to flash those on a non-addressable area. This would result in an error during the flash process. Let’s say we use an GCC makefile based project. With the most modern compiler it is possible to separate a part of the build binary and extract respectively store these data in a separate binary file. Within our Build Environment often a section is predefined, where all bitmap and font resources can be linked into. To have this setting is a minimum requirement for this task.
For instance, the STM32F746 has this option already available within its GCC makefile, cause it is already using an external QSPI flash. In comparison to that, the iMXRT1050 makefile is configured without external memory and thus also without this option within its GCC makefile project. This requires to add this setting. For that, the STM32F746 makefile can be used to take as example, to see what the macro ‘EXTERNAL FLASH’ effects within the makefile.
Let’s assume that at this point both GCC projects already have included the setting to force linking the bitmap and font resource into a user defined section. This section have to be taken into account within your linker script memory are, which is not directly addressable.
When starting a build process, the project builds all üroject files normally. The linker process then will give the bitmap and font resources an address within the ’virtual’ memory area, which doesn’t really exists. A typical flash tool requires a binary with the information which data goes to which address. Within the ‘normal’ binary, the section with the bitmap and font resources have to be excluded, which means, only data that is directly addressable will be flashed.
The flash tool won’t try to flash the binary which is dedicated to be stored on the non-addressable memory. This data have to be copied to the external non-addressable flash area seperatly. For example for a NAND memory by a dedicated flash loader or in case of an SD card by manually copy it with a computer.
Within your IDE project, we now have to inform Embedded Wizard that if it would like to request data from the non-addressable memeory, it have to use an external flash loader to access those. When registering an external flash loader, Embedded Wizard needs information about which memory area is ‘virtual’. Thus a reading process to data linked into the 'virtual' memory area, will be forwarded to the external flash reader instead of accessing the data directly. Shortly spoken, the external flash loader ‘simulates’ the non-accessible memory area. For this, it is important to register the flash loader, this can be look like that:
In combination with the documentation about this function, we can see that it requires a flash read function, the start address and end address of the non-addressable memory area. From Embedded Wizards point of view, only this function call before invoking EwInitGraphicsEngine() is required.
Please take into account that the external flash reader have to be developed separately and isn't a part of the Embedded Wizard solution.
Furthermore, in fact we can provide an easy to use example for STM32F746 and iMXRT1050. This example is designed as an add-on to our normal build environment. So, let’s bring up that example on your board. For that, please follow the next steps.
1. Please download a Embedded Wizard Build Environment for STM32F746 or iMXRT1050.
As you can see in the board specification of the STM32F746 or iMXRT1050, both do have a SD card slot. Therefore both example use the SD card as external non-addressable memory area. Only the STM32F746 has a external QSPI flash mounted, but we do not want to use this chip. In this example we would like to ‘replace’ the QSPI flash by the SD card and on the iMXRT1050 we want to additionally use the SD card binary data.
2. Download the external flash loader example add-on package for STM32F746 or iMXRT1050. Please take in to account that the add-on was made for an Embedded Wizard 10.0 Build Environment.
3. Unzip the Build Environment from step 1 first and then unzip and merge all files from step 2 into the Build Environment. This process will add or replace code and files like driver for the SD card to your Build Environment.
4. Open the Embedded Wizard Example 'Example/HelloWorld' and build the project like explained in the related getting started article for STM32F746 or iMXRT1050. For this please use the GCC project, which means simply double click on 'StartGcc BuildEnvironment.bat' and enter 'make'. This will build the project and separates the binary into two parts. One part is dedicated for the internal RAM and ROM, and the other is dedicated for to be stored on a SD card. In the GCC output folder you can find a binary file '…Extern.bin'. This file contains the data which have to be copied to a SD card.
5. Please copy the binary to the SD card. This requires a special flash tool, we can recommend Win32DiskImager. Due to the fact that we do not want to use a file system, it is important to copy the data bitwise and not formatted for a file system like FAT32. If you would drag and drop the binary file to the SD card via a file explorer, the board couldn't read the data properly. Maybe you know this approach from flashing an OS for a raspberry pi, this is a similar process.
So, after you’ve installed and opened Win32DiskImager please select the '…External.bin' file with the file browser. To make that file visible, please take care to allow showing all file format by changing the property at the lower right dropdown.
Finally press “Write” to copy the binary bitwise to the SD card.
7. Insert the SD card into the card slot of the STM32F746 or iMXRT1050. Now the bitmap and font resources are stored on a non-addressable memory.
8. Open ‘StartGccBuildEnvironment.bat’ again and enter ‘make install’. This will flash the rest of the application. After the automatically reset at the end of the process, you can see in your terminal application that your board requires a SD card and the external flash loader will be registered.
For example, here for the STM32F746:
… and here for the i.MXRT1050:
Now the running Embedded Wizard application uses the font and bitmaps data which are stored on the SD card.
Please also take care, that the SD card add-on only can be used with the GCC project. Currently no other IDEs are supported. Due to limited flexibility in flashing a binary and sperating it into two peaces, setting up a project for example for MCUXpresso or STM32CubeIDE would definitely take some further research.
Hopefully this helps,
Best regards,
Tim
