Using Keil to load binary into external SPI Flash

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Using Keil to load binary into external SPI Flash

537 Views
rhsalced
Contributor I

Hello,

I'm wondering if there's a way to load a random binary file into external SPI flash using Keil. The binary file will pass through the LPC54102 (OM13077 EVK board). I know some ISEs for FPGAs allow you to do this, curious if this is possible with the LPC54102 using Keil.

Obviously Keil will need to know what SPI flash is connected to the LPC, along with other details like, SPI port, clk speed, etc. 

 

Does anyone know is Keil can do this? 

 

image.pngThanks!

0 Kudos
Reply
1 Reply

514 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

Hello @rhsalced 

- You can refer to this thread:

https://community.nxp.com/t5/LPC-Microcontrollers/LPC54018JxM-debugging-internal-flash-example-for-K...  

It introduces lpc54018 + QSPI flash + KEIL.。

-  1. If the default selected Flash download algorithm file is not applicable to your board, then you need to provide a suitable algorithm file (.FLM) yourself and place it in the MDK installation directory (\Keil_v5\ARM\Flash). Then, reopen the project options, and the newly added algorithm will be automatically refreshed into the list of selectable algorithms.

1.jpg

2. After obtaining the appropriate download algorithm file, you finally need to check two address ranges. One is the actual mapped address space corresponding to the Flash, and the other is the running RAM address space of the download algorithm file.
 
2.jpg

3. NOR Flash Download Algorithm Design
The Flash download algorithm under Keil MDK is open-source and comes with relatively detailed documentation. The documentation can be found on the GitHub homepage of arm-software. Based on these documents, we can basically understand the design details of its download algorithm.
Algorithm Homepage: 

3.1 Download Algorithm Template Project
Keil MDK provides a basic template project for the Flash download algorithm. The project is located at \Keil_v5\ARM\Flash_Template\NewDevice.uvprojx. This project can only be compiled using MDK (not supported by MDK-Lite). In addition to the project settings, this template project only contains four files:

\Keil_v5\ARM\Flash\FlashOS.h
\Keil_v5\ARM\Flash_Template\FlashDev.c
\Keil_v5\ARM\Flash_Template\FlashPrg.c
\Keil_v5\ARM\Flash_Template\Target.lin

After obtaining the basic template project, we need to change the default ARMCM0 core in the project options according to the type of the target MCU core. Then, we need to implement all the algorithm API functions in FlashDev.c and FlashPrg.c (they are empty by default). Finally, compile the project to generate the.FLM file, which is the algorithm file we need (in fact, the final.FLM file is obtained by directly renaming the.axf file through the script command in After Build. The.FLM file is essentially an axf format file).

4444.jpg

3.2 Download Algorithm Structure Design
The structure of the algorithm itself is actually very simple. In the FlashDev.c file, there is a constant structure named FlashDevice, and its prototype is defined in FlashOS.h. This structure mainly provides the necessary Flash information for the IDE, and its values must be filled in correctly according to the actual situation of the board.
 
struct FlashDevice const FlashDevice  =  {
   FLASH_DRV_VERS,             // Driver Version, do not modify!
   "New Device 256kB Flash",   // Device Name 
   ONCHIP,                     // Device Type
   0x00000000,                 // Device Start Address
   0x00040000,                 // Device Size in Bytes (256kB)
   1024,                       // Programming Page Size
   0,                          // Reserved, must be 0
   0xFF,                       // Initial Content of Erased Memory
   100,                        // Program Page Timeout 100 mSec
   3000,                       // Erase Sector Timeout 3000 mSec

// Specify Size and Address of Sectors
   0x002000, 0x000000,         // Sector Size  8kB (8 Sectors)
   0x010000, 0x010000,         // Sector Size 64kB (2 Sectors) 
   0x002000, 0x030000,         // Sector Size  8kB (8 Sectors)
   SECTOR_END
};

 

In addition to FlashDevice, the most core part is of course the seven API functions in FlashPrg.c. These API functions provide the actual functions of Flash erasing, programming, and verification. The IDE will automatically call these APIs as needed to achieve online downloading. The prototypes of these APIs are fixed, but the specific function implementations vary depending on the board.
55555.jpg

 

There is also a design of the algorithm project that has to be mentioned, that is, both Read-Only Position Independent and Read-Write Position Independent are checked under the project options C/C++ (including Asm). This indicates that the download algorithm itself is not linked using a fixed address, but is a position-independent link (also called a relative address link). The machine code of the algorithm code can be executed at any address, which is why you can specify the RAM for Algorithm in the example options.
 
66666.jpg
 
 
 (The  above steps on how to develop a suitable download algorithm file are from a Chinese article https://blog.csdn.net/Henjay724/article/details/109153585 . It is based on I.MX RT, and I just  translated it into English. )
 
 
BR
Alice

 

 

0 Kudos
Reply