Deploying LatticeMico32 Software to Non-Volatile Memory

Transcription

1 February 2008 Introduction Technical Note TN1173 The LatticeMico32 Software Developers Guide describes how to deploy firmware onto hardware that provides both non-volatile memory and volatile memory. The LatticeMico32 (LM32) evaluation boards provide a large amount of Flash memory and a modest amount of asynchronous SRAM. They also provide for the addition of a decent amount of DDR memory. However, not all LatticeMico32-based platforms have large amounts of volatile memory available. The software application may not be very large, or may not require a lot of volatile memory. Such systems will do away with adding asynchronous SRAM, SDRAM, or DDR memories. For a number of reasons, it may be desirable to create a LatticeMico32-based system that only has non-volatile memories attached to the FPGA that act as the bulk program store. Volatile data will be managed inside the FPGA using Embedded Block RAM (EBR) resources. This technical note describes the changes that must be applied to the C/C++ development environment in order to deploy execute In Place (XIP) projects. System Requirements In order for the procedure described in this technical note to succeed in deploying a XIP project, the LatticeMico32 platform must meet a minimum set of requirements: 1. LM32 processor with debug enabled, clock, reset strobe 2. Flash memory large enough to hold XIP code and initialized data K bytes volatile memory 4. USB JTAG connection Items #1 and #2 should be present by design. Item #3 is a requirement for Step 12 to succeed. The Deploy to Flash function available to LatticeMico32 designers currently requires ~80Kbytes of memory to store all of the code. This memory requirement exceeds the internal memory of most FPGA devices. It is up to the designer to determine alternate programming methods if providing the additional RAM is undesirable. LatticeMico32 Software Developers Guide Boot Procedure The LatticeMico32 Software Developers Guide describes how to deploy firmware projects. However, these projects only use the non-volatile memory as a way to keep the firmware available between power cycles. It doesn t run the firmware from the non-volatile memories. The software deployment method described in the LatticeMico32 Software Developers Guide deploys your firmware. In addition, it prepends a piece of code that copies your firmware from the non-volatile memory to a volatile memory. Your firmware runs from the volatile memory once the copy is completed. There must be enough volatile memory to hold all of the opcodes, initialized data, uninitialized data, and the stack. Deploying to Flash for XIP Deploying LatticeMico32 Software to Non-Volatile Memory It is desirable for some systems to forgo copying the firmware from a non-volatile memory to a volatile memory. This means the opcodes are executed in place, i.e. directly from the non-volatile memory. The process described in this technical note assumes there is still some amount of initialized, uninitialized, and stack data. The expectation is this data will reside inside the FPGA EBR memories Lattice Semiconductor Corp. All Lattice trademarks, registered trademarks, patents, and disclaimers are as listed at All other brand or product names are trademarks or registered trademarks of their respective holders. The specifications and information herein are subject to change without notice. 1 tn1173_01.0

2 XIP Considerations Using XIP has the advantage of reducing the cost of an embedded system by eliminating unnecessary components. The hardware is reduced in cost and complexity. The disadvantage of using XIP occurs in the software development cycle. It is slower to deploy new firmware images to the non-volatile memories due to an increase in the amount of time it takes to program the memory. Flash PROM requires a lengthy erase and program cycle. In addition to the slow reprogram time, code run from the non-volatile memory is likely to be slower than code run from a non-volatile memory. LatticeMico32 cache memories are likely to be smaller or non-existent, which means memory cycle times are likely to have several wait states. The result of the wait states will be lower overall processor performance. Another disadvantage is the loss of access to the Eclipse debug environment. The Eclipse debug environment depends on the ability to download code and insert debug exception instructions into a volatile memory space. XIP-based platforms do not have this ability. Debugging XIP-based LatticeMico32 projects must be done using stand-alone GDB (i.e. lm32-elf-gdb). XIP Deployment Process The procedure described here allows the program opcodes to be stored and run from the non-volatile memory, and application data to be stored in a scratchpad RAM. 1. Copy DDInit.c from the platform library folder to the project folder as shown in Figure 1. A managed LatticeMico32 C/C++ project invokes the LatticeDDInit() function. The LatticeDDInit() function is located in the DDInit.c source file copied from the LatticeMico32 component subdirectory the first time the managed make source is compiled. The LatticeDDInit() function is ultimately combined with other platform source files and an object library is created. The object library is then linked to your project source code. The XIP project needs to override the default behavior of the LatticeDDInit() function. As long as the function prototypes remain identical it is possible to do this by copying the DDInit.c file from the platform source subdirectory to your C project subdirectory. This creates a new object file that gets linked with your other project source files. Adding new functions or changing the number/type of passed parameters to existing functions in the DDInit.c source causes compile and link time errors. 2

3 Figure 1. Copying DDInit.c 2. Modify DDInit.c as shown in Figure 2. Figure 2. Modifying DDInit.c #include DDStructs.h #ifdef cplusplus extern C #endif /* cplusplus */ void LatticeDDInit(void) // Insert these two statements extern void copy_data_section(void); copy_data_section(); /* initialize LM32 instance of lm32_top */ LatticeMico32Init(&lm32_top_LM32); /* initialize flash instance of asram_top */ LatticeMico32InitCFIFlashDriver(&asram_top_flash); /* initialize uart instance of uart_core */ MicoUartInit(&uart_core_uart); /* initialize LED instance of gpio */ MicoGPIOInit(&gpio_LED); 3

4 } /* invoke application s main routine*/ main(); #ifdef cplusplus }; #endif /* cplusplus */ Steps 1 and 2 must be performed any time a peripheral is added or removed from the MSB platform. 3. Create a new source file named copy_data_section.c in the project, as shown in Figure 3, and add the code provided in Figure 4 to the file. Figure 3. Adding copy_data_section.c Figure 4. Adding Code to copy_data_section.c #ifdef cplusplus extern C #endif /* cplusplus */ extern unsigned int _edata; extern unsigned int _fdata; extern unsigned int _erodata; void copy_data_section(void) unsigned int loopvar; unsigned int n_chars = (unsigned int)&_edata - (unsigned int)&_fdata; char *dst; char *src; } dst = (char *) &_fdata; loopvar = ((unsigned int)&_erodata & ~3); src = (char *)loopvar; for (loopvar = 0; loopvar < n_chars; loopvar++, src++, dst++) *dst = *src; #ifdef cplusplus }; #endif /* cplusplus */ 4

5 The non-volatile image stores several sections of data. The.text section stores all of the LatticeMico32 opcodes. There are several data sections as well. One of these sections contains all of the initialized read/write data. The code in Figure 4 relocates the initialized read/write data to a volatile memory. The nonvolatile memory also stores all initialized read only data. The read/write data will be linked and placed after the read-only data. The symbols _edata, _fdata and _erodata are defined in the default linker script. These symbols define the address of the first read/write element, the last read/write element, and the last readonly element. 4. The necessary C/C++ code changes are now in place and the linker script needs to be updated for the XIP function. Copy the linker.ld file from within the build-configuration directory of the platform directory to the project directory as shown in Figure 5. Figure 5. Copying linker.ld 5. Open the linker.ld file and make sure the.boot,.text and.rodata sections are assigned to Flash, as shown in Figures 6 and 7. The target location name, flash in this example, is based on the MSB instance name of the non-volatile memory component. Figure 6. Assigning.boot and.text to Flash Region /* code */.boot : *(.boot) } > flash.text :. = ALIGN(4); _ftext =.; *(.text.stub.text.*.gnu.linkonce.t.*) *(.gnu.warning) KEEP (*(.init)) KEEP (*(.fini)) /* Exception handlers */ *(.eh_frame_hdr) KEEP (*(.eh_frame)) *(.gcc_except_table) /* Constructors and destructors */ KEEP (*crtbegin*.o(.ctors)) KEEP (*(EXCLUDE_FILE (*crtend*.o ).ctors)) KEEP (*(SORT(.ctors.*))) 5

6 KEEP (*(.ctors)) KEEP (*crtbegin*.o(.dtors)) KEEP (*(EXCLUDE_FILE (*crtend*.o ).dtors)) KEEP (*(SORT(.dtors.*))) KEEP (*(.dtors)) KEEP (*(.jcr)) _etext =.; } > flash =0 Figure 7. Assigning.rodata to flash /* read-only data */.rodata :. = ALIGN(4); _frodata =.; _frodata_rom = LOADADDR(.rodata); *(.rodata.rodata.*.gnu.linkonce.r.*) *(.rodata1) _erodata =.; } > flash 6. Modify the.data section as shown in Figure 8. The modification, AT( ADDR(.rodata) + SIZEOF(.rodata) ) tells the linker that the.data section is after the.rodata section in the fully linked ELF output. Figure 8. Modifying.data Section /* read/write data */.data : AT (ADDR(.rodata) + SIZEOF(.rodata)). = ALIGN(4); _fdata =.; *(.data.data.*.gnu.linkonce.d.*) *(.data1) SORT(CONSTRUCTORS) _gp = ALIGN(16) + 0x7ff0; *(.sdata.sdata.*.gnu.linkonce.s.*) _edata =.; } > sram 7. The read/write memory must reference a volatile memory. The.data section in this example points to the MSB component instance named sram. An instance name for any volatile memory in your platform is valid. Place the component instance name at the last line of Figure 8. This informs the linker that the.data section is assigned to a volatile memory component (SRAM) even though it is appended to the.rodata section, which is in Flash. The copy_data_section function is executed after the LatticeMico32 is released from reset. This code, contained in the.text section, copies the.data section from the Flash component to the SRAM component. The copy must be done before any code attempts to access a variable located in the.data section (i.e. sram). 8. By default, LatticeMico32 C/C++ projects invoke an automatically generated linker script. For most projects this is acceptable. The C/C++ linker script that is to be invoked needs to be changed for a XIP project. This is done by right-clicking on the Software Project name and selecting Properties. Select Platform in the dialog, and then change the linker script to be used, as shown in Figure 9. The script file must be the linker.ld file updated as described in steps 5 through 7. Figure 9 also provides controls for how to handle Stdio Redirection. XIP projects do not have access to the JTAG UART function. Change the stdin, stdout, and stderr entries to RS-232(uart). Do not leave these set to default to the JTAG UART. 6

7 When the changes in this step are completed, close the dialog. Figure 9. Using Custom Linker Script 9. The C/C++ code is now ready to be built as a XIP project. Right-click on your C/C++ project name and rebuild the source from scratch. You can verify the build succeeded in creating a XIP image by performing steps 10 and 11. Skip to step 12 if you want to deploy and run the code. 10.Launch LatticeMico32 System SDK Shell and change to the directory containing the rebuilt executable (.elf) file as shown in Figure 10. The executable file will, by default, reside in the Debug subdirectory of the C/C++ project. Figure 10. LatticeMico32 System Cygwin Shell 7

8 11.In the LatticeMico32 System SDK Shell window, enter lm32-elf-objdump -h <Application_name>, as shown in Figure 11. Figure 11. lm32-elf-objdump -h led_test.elf led_test.elf: file format elf32-lm32 Sections: Idx Name Size VMA LMA File off Algn 0.boot ec **0 CONTENTS, ALLOC, LOAD, READONLY, CODE 1.text c ec ec ec 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 2.rodata f f f8 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 3.data a **2 CONTENTS, ALLOC, LOAD, DATA 4.bss **2 ALLOC 5.comment d **0 CONTENTS, READONLY 6.debug_aranges e ad 2**0 7.debug_pubnames 00000abe c8d 2**0 8.debug_info 0000a3bc b 2**0 9.debug_abbrev 00001af eb07 2**0 10.debug_line 00004c f9 2**0 11.debug_str 00000a c 2**0 12.debug_ranges cc4 2**0 For this platform, the Flash memory component is located at 0x and the SRAM is located at 0x In the example above, the.boot,.text and.rodata sections are located in Flash (LMA) and their assigned addresses (VMA) are also in Flash. The.data section is located in Flash (LMA) and the assigned address is in VMA. The modifications to LatticeDDInit ensure that the initialized read/write data defined in the.data section is copied to the beginning of the SRAM. The copy begins at the LMA of the.rodata + sizeof(.rodata) section and copies sizeof(.data) bytes to the VMA of the.data section. It is important to be careful not to access variables in the.data section during the boot process when using XIP. The boot code in crt0ram.s does not access variables in the.data section. This makes it is safe to perform the.data section relocation in LatticeDDInit. The.bss section VMA and LMA are assigned addresses in SRAM by the linker. The.bss section contains uninitialized variables and defines the start of stack space. The code in crt0ram.s writes zeroes to the.bss section on startup. 12.Deploy the XIP project to your non-volatile memory. The actual deployment method depends upon the platform hardware. Assuming the platform meets the minimum requirements the Tools->Software Deployment method described in the LatticeMico32 Tutorial can be used. 8

9 If you are using the Tools->Software Deployment method and are deploying to SPI PROM or CFI Parallel PROM, it is important to make sure the Prepend Code Relocator control is not enabled (i.e. unchecked). If the Prepend Code Relocator control is enabled, you will get the default behavior where the boot code tries to copy the non-volatile image into a volatile memory. In most cases, this means the boot process will fail. Debugging XIP Projects The XIP project has special requirements regarding debug sessions. The Eclipse invocation of the LatticeMico32 GDB implementation requires the platform to have the opcodes stored in a read/write memory. The XIP project does not meet this requirement. The debug environment for XIP is, therefore, only available outside the Eclipse UI. This section describes how to get the GDB debugger to connect to the LatticeMico32 processor. It does not describe how to use GDB beyond comments on a few necessary extensions within the debugger. In order to debug your XIP code it is necessary to invoke two LatticeMico32 System SDK Shell tools. In one of the two SDK shells type: TCP2JTAGVC2 This command allows the lm32-elf-gdb tool to communicate to the LatticeMico32 processor using the JTAG cable. Make sure any firewall software does not block the TCP/IP port this program uses to communicate to GDB. In the other SDK shell, perform the following: 1. Change directory to your C/C++ ELF file 2. Invoke the LatticeMico32 GDB tool lm32-elf-gdb <your_c_project>.elf 3. Wait for the GDB tool to load 4. From the GDB command line type: target remote localhost: After a certain amount of time the debugger should respond with an address located inside the LatticeMico32 Debug Address range. When the debugger responds, you are now able to begin your debug work using available GDB commands. Some special commands that permit debug of XIP programs: a. hbreak : Assigns a breakpoint at a legal instruction. For LatticeMico32 the address must be dword aligned. b. thbreak : Performs the same function as hbreak except the breakpoint is cleared after it is executed. These special commands are only available when the Enable Debugging Code in Flash or ROM function is enabled in your LatticeMico32 instance, and the number of breakpoint registers is non-zero. Hardware Breakpoint Registers are used to perform address comparisons against the current program counter. Hardware Watchpoint Registers are used to perform address comparisons against the current data transaction address. Each hbreak/thbreak uses one of the Hardware Breakpoint Registers. Technical Support Assistance Hotline: LATTICE (North America) (Outside North America) techsupport@latticesemi.com Internet: 9

10 Revision History Date Version Change Summary February Initial release. 10