AN1816 APPLICATION NOTE
Configuring the Keil Compiler and PSDsoft to Handle Multi-Paged Memory in PSD Application Software
PSD devices have an 8032 core, and an extremely large array of Flash memory bigger than the 64-KByte address limit of the 8032 core, in fact. A built-in 8-bit Page Register allows the user to break this restrictive limit, by dividing the memory into pages (as shown in Figure 1), thereby increasing the addressing capability of the core by as much as 256 times. This is possible because the outputs of the Page Register (PGR0-PGR7) are inputs to the DPLD decoder, and can be included in the Sector Select (FS0-FS7, CSBOOT0-CSBOOT3), and SRAM Select (RS0) equations, and because the MCU has complete read/ write access to the Page Register. This facility can, of course, be managed manually. However, the Keil compiler/linker allows it to be managed automatically, too, if the options are set up appropriately in the VISION2 and PSDsoft environments. (PSDsoft, VISION2 and an evaluation version of the Keil software are available on CDs that come with PSD demonstration kits). This application note steps you through the configuration process of setting up Keil and PSDsoft for code paging. (The term "bank" in the Keil tool is equivalent to the term "page" in the PSDsoft Express tool, and the two terms are used interchangeably throughout this application note.) Figure 1. Example Memory Map for a PSD3234 Device
8032 Program Space (PSEN) Page 0 FFFFh Page 1 Page 2 Page 3 Page 4 Page 5 Page 6 Page 7 FFFFh 8032 XData Space (RD and WR) Page X
FS0 32 KByte
FS1 32 KByte
FS2 32 KByte
FS3 32 KByte
FS4 32 KByte
FS5 32 KByte
FS6 32 KByte
FS7 32 KByte
System I/O 8000h 6000h CSBOOT2, 8 KBytes Common Memory to All Pages 4000h 2000h 0000h CSBOOT1, 8 KBytes Common Memory to All Pages CSBOOT0, 8 KBytes Common Memory to All Pages 4000h 2000h 0200hCSIOP -02FFh 256 Bytes 0000h
AI09077
CSBOOT3, 8 KBytes Common Memory to All Pages
RS0 8 KBytes
May 2004
1/13
AN1816 - APPLICATION NOTE
Figure 1 is an example of a typical memory map for PSD3234 devices. There are many possible memory maps because of the programmable address decode logic inside the PSD device, but this map is a typical one. Memory maps for other PSD devices (PSD3212, PSD3233, and PSD3254) differ slightly from Figure 1 because these devices have different sized SRAM and Flash memory sectors. In Figure 1, the top half of the Code space (8000h-FFFFh) is setup for code paging (banking). The value of the Page Register in the PSD will determine which Flash Sector is mapped to this physical address space (8000-FFFF). The bottom half of the Code space (0000h-7FFFh) does not change, but is common to all code pages, and is not affected by the contents of the Page Register. BANKIN G OPTIONS First, in the VISION2 environment, set up the options for main target file. You can do this with the menu command "Project / Options for Target...", or by clicking the right mouse button on the main target (displayed as the root of the tree in the project window). On the "Target" tab, as shown in Figure 2, check the "Code Banking" option, to enable the feature, and select the number of banks that you want to use. Define the start and end address of the bank area to match the memory map that you want to use. Figure 2. Setting the "Project / Options for Target / Target" Screen
2/13
AN1816 - APPLICATION NOTE
Then, you can set up the options for each of the source code modules that you want to have in the banked Flash memory, as shown in Figure 3, by right-clicking on the source code file name, and selecting "Options". You will need to select the page or code bank in which this specific source code is to be located. If you do not select a code page, the compiler will default to a page where it can be fitted. To specify a specific page, select the Code Bank, pull down and select the bank page number. "Common" places the code in the lower, common code area. Figure 3. Setting the Options for Each Module of Banked Flash Memory
3/13
AN1816 - APPLICATION NOTE
EDITS TO THE KEIL BANKING START-UP FILE In the L51_bank.a51 file you should make the following adjustments (as shown in Figure 4):
Set the B_NBANKS constant to 8 (this defines the maximum number of banks) Set the B_MODE constant to 1 (bank-switching via the XDATA port) Set the B_XDATAPORT constant to 2E0h (CSIOP will be mapped at 200h, and the PAGE register resides at address E0h). Set the B_FIRSTBIT constant to 0.
Figure 4. After the Adjustments to the L51_bank.a51 File ... ;* * ** * ** * ** * ***** Configuration Section * * ** * ** * ** * ** * ** * ** ?B_NBANKS EQU 8 ; Define maximum Number of Banks * ; ; following values are allowed: 2, 4, 8, 16, 32, 64 * ; ; for BL51 the maximum value for ?B_BANKS is 32 * ; ; for LX51 the maximum value for ?B_BANKS is 64 * ; * ?B_MODE EQU 1 ; 0 for Bank-Switching via 8051 Port * ; ; 1 for Bank-Switching via XDATA Port * ; ; 4 for user-provided bank switch code * ; * ... IF ?B_MODE = 1; * ;----------------------------------------------------------------------------* ; if ?BANK?MODE is 1 define the following values * ; For Bank-Switching via XDATA Port define XDATA Port Address / Bits * ?B_XDATAPORT EQU 2E0H ; default is XDATA Port Address 2E0H * ?B_FIRSTBIT EQU 0 ; default is Bit 0 * ;----------------------------------------------------------------------------* ENDIF; * ; *
4/13
AN1816 - APPLICATION NOTE
DIRECT FUNCTION CALLS Now you can directly call, from one bank, a function that is located in another bank. For example, from Bank-1 you might want to call a function that is located in Bank-2. So, in Bank-1 you might have the following code: extern void called_function (void);//reference to function in other module void calling_function (void)//function which calls { called_function();//function which is being directly called } And somewhere in Bank-2 you could have the implementation of the function: void called_function (void)//called function implementation { ...user code... }
INDIRECT FUNCTION CALLS In a more complex example, you might want to call, from Bank-1, a function that is located in Bank-2, and to have this function call a callback function located back in Bank-1. So, in Bank-1 you might have the following code: typedef void (code* ptr_fnc) (void);//type definition of pointer to function extern void called_function (ptr_fnc callback_function); //reference to function in other module void return_here (void)//callback function implementation { ... user code ... } void calling_function (void)//function which calls { called_function (return_here);//function which is being directly called } //with callback address in parameter
5/13
AN1816 - APPLICATION NOTE
And somewhere in Bank-2 you might have this function: typedef void (code * ptr_fnc) (void);// pointer to function type definition void called_function (ptr_fnc callback_function) { //called function, it takes callback addres in parameter callback_function();//and calls it indirectly } The address of the callback function is passed as a pointer. But the pointer only contains an address, without any information about the Page Register. Therefore, at the point of execution of the callback function, the processor would jump to the destination address, but within the current memory bank. This is caused by the linker, which does not create an entry in the call tree for functions that indirectly call functions in other banks. To get round this, you have to set up the relation between calling and called functions. The Overlay linker directive is used for this purpose. This is achieved by filling in the appropriate text in the "Overlay" field of the BL51 Misc tab of the "Project / Options for Target" screen. In the example, above, the appropriate text would be: "called_function ! return_here", as shown in Figure 5. This adds a reference from called_function to return_here (the function call that is made via the function pointer). Figure 5. Setting the "Project / Options for Target / BL51 Misc" Screen
6/13
AN1816 - APPLICATION NOTE
CHECKING THE OUTPUT FROM THE COMPILER At this point, the user might like to make sure that the Keil compiler created what was intended. Look inside the project directory and see if the banked object and HEX files are present. Banked object files are those with file extension B00, B01 etc.; HEX files are named *.H00, *.H01 etc. If the files are not there, you have to enable the "Create HEX File" setting, as shown in Figure 6. Figure 6. Setting the "Project / Options for Target / Output" Screen
7/13
AN1816 - APPLICATION NOTE
PSDSOFT EXPRESS SETUP In PSDsoft Express, configure both Primary and Secondary Flash memories to reside in program space only, as shown in Figure 7. Figure 7. Setting the Options in the "MCU/DSP and PSD Selection" Screen of PSDsoft Express
8/13
AN1816 - APPLICATION NOTE
You should enable the correct number of bits in the Page Register, according to number of the banks you use. The number of pages that you can control using N bits, is 2N. For example, for 8 pages, you will need three Page Register bits. This can be done via the "Define PSD Pin/Node Functions" box in Design Flow diagram. Clicking on the "Next" button in the "Pin Definitions" window invokes the "Design Assistant" window. On the first tab, "Page Register Definition", select the bits that you need, as shown in Figure 8. Figure 8. Setting the Options in the "Design Assistant / Page Register Definition" Screen of PSDsoft Express
9/13
AN1816 - APPLICATION NOTE
CONSISTENCY OF THE MEMORY MAP BETWEEN THE KEIL COMPILER AND PSDSOFT EXPRESS Then press the "Next" button again, and on the "Chip Select Equations" tab, as shown in Figure 9, define the memory map in such as way that it is consistent with the settings that were made on the Keil compiler "Target" screen, back in Figure 2. In the example, all banks used address range 8000h-FFFFh. Therefore:
For FS0, select Page Number 0 and address range 8000h-FFFFh For FS1, select Page Number 1 and the same addess range And so on, for the remaining sectors of Main Flash memory, FS2 ... FS7. Then, specify the address range 0000h-1FFFh for the Secondary Flash memory segment CSBOOT0. Do not specify a Memory Page Number, because the Secondary Flash is present on all pages. And so on, for remaining sectors of Secondary Flash memory, CSBOOT1 ... CSBOOT3. Check that the start address of CSIOP (the PSD module register base address) is set to 200h. This is important, to maintain consistency with Keil's L51_bank.a51 file. Do not include the Page number setting here. Check that RS0 is at 2000h. The RAM should be accessable from any bank, and should not be qualified by the Page Number value, either.
Figure 9. Setting the Options in the "Design Assistant / Chip Select Equations" Screen
10/13
AN1816 - APPLICATION NOTE
MERGING THE MCU FIRMWARE WITH THE PSD After that, finish the setup by pressing the "Done" button, and run the "Fit Design to Silicon" command from the Design Flow diagram. Then, click on the "Merge MCU/DSP Firmware with PSD" box, as shown in Figure 10, and in the dialog boxes, select the HEX files for each of the banks that you are using. For CSBOOT0, select the same HEX file that you had used for FS0, and set the address range to 0000h1FFFh. Then click the "OK" button. If the merging succeeds, you can then proceed to program the chip, using the JTAG interface, with the object file that you have created. The output of this merging process produces an .OBJ file which combines the program source code, and PLD configuration options, into one file that will be programmed into the PSD. Figure 10.
11/13
AN1816 - APPLICATION NOTE
REVISION HISTORY Table 1. Document Revision History
Date 27-May-2004 Version 1.0 First Issue Revision Details
12/13
AN1816 - APPLICATION NOTE
For current information on ST PSD products, please consult our pages on the world wide web: www.st.com/psm If you have any questions or suggestions concerning the matters raised in this document, please send them to the following electronic mail addresses: apps.psd@st.com ask.memory@ st.com (for application support) (for general enquiries)
Please remember to include your name, company, location, telephone number and fax number.
Information furnished is believed to be accurate and reliable. However, STMicroelectronics assumes no responsibility for the consequences of use of such information nor for any infringement of patents or other rights of third parties which may result from its use. No license is granted by implication or otherwise under any patent or patent rights of STMicroelectronics. Specifications mentioned in this publication are subject to change without notice. This publication supersedes and replaces all information previously supplied. STMicroelectronics products are not authorized for use as critical components in life support devices or systems without express written approval of STMicroelectronics. The ST logo is a registered trademark of STMicroelectronics. All other names are the property of their respective owners 2004 STMicroelectronics - All rights reserved STMicroelectronics GROUP OF COMPANIES Australia - Belgium - Brazil - Canada - China - Czech Republic - Finland - France - Germany - Hong Kong - India - Israel - Italy - Japan Malaysia - Malta - Morocco - Singapore - Spain - Sweden - Switzerland - United Kingdom - United States www.st.com
13/13
|