1 / 76

The GreenHills Tool Chain

The GreenHills Tool Chain. Multi 2.1/3.5 Differences Build Environment Overview Build Through Debug Review Linking Files ROM and RAM Execution Multi 2000 Configuration. Multi 2.1/3.5 - Directory Structure. Multi v2.1 C:green libsrc armtsf armtsfb.

quinta
Télécharger la présentation

The GreenHills Tool Chain

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The GreenHills Tool Chain Multi 2.1/3.5 Differences Build Environment Overview Build Through Debug Review Linking Files ROM and RAM Execution Multi 2000 Configuration 7-1

  2. Multi 2.1/3.5 - Directory Structure Multi v2.1 C:\green \libsrc \armtsf \armtsfb Multi v3.5 C:\ghs \libsys \arm4 \arm4b 7-2

  3. Multi 2.1/3.5 - System Library • System related functions • libsys.a • Contains customized IO stubs • ind_io.c • No longer replace system library in GHS directory • /ghs/arm4b/libsys.a • New custom GHS library • ghs.o • Replaced io file during final link • na2.bld 7-3

  4. Multi 2.1/3.5 - Build File • Compatible with multi2000 v3.5 • na1.bld, na2.bld, bsp.bld, … • Automatically upgraded format when modified • Insert additional files • Options are added or removed • byteorder • bigendian • c_options • New format not compatible with v2.1 • Using an editor to avoid format change • Wordpad • ultraedit 7-4

  5. Multi 2.1/3.5 – new Compiler • Stricter compliance to C standard • Casting variable types • Additional warnings generated • No line feed • Variable used when not initialized • Variable not used • NETOS files cleaned • bsp, header files, examples 7-5

  6. Overview of Multi 2000 Build Environment 7-6

  7. Major Components • By Green Hills Software • Integrated Development Environment (IDE) Includes • Builder • Compiler • Linker • Editor • Source Debugger • Version Control • Run-Time Error Checking 7-7

  8. Builder Window • This is the main builder window 7-8

  9. Graphical User Interface • Multi-2000 provides a color-assisted text editor 7-9

  10. Adding files to the project • C files and libraries are added to the project simply by a multi-selectable dialog window 7-10

  11. Build Through Debug Review 7-11

  12. Building the project • Once all files are present in project workspace, building is readily done 7-12

  13. Connecting to Target (1of 3) • In the Builder, choose Remote > Connect to Target. 7-13

  14. Connecting to Target (2 of 3) • Enter OCDSERV command line. 7-14

  15. Connecting to Target (3 of 3) • Two new windows • IN/OUT –Displays Printf’s • TARGET—can read/write to Memory/CPU 7-15

  16. Starting Debugger • In the Builder select Debug > debug 7-16

  17. Debugger Features • Set Break Points-Software and Hardware • Step through code • Examine C-code • Examine Interlaced Assembly • Examine values of variables, registers, memory 7-17

  18. Debugger Windows • Interlaced Assembler displayed • Color enhanced buttons 7-18

  19. Download code to Target • Click“play” button or (F5) 7-19

  20. Run Program • Program is Running • Use breakpoints or step through code 7-20

  21. Breakpoints • NET+OS supports both software and hardware breakpoints. • Software breakpoints (instruction fetches) are only possible while debugging from RAM • Actual instruction is replaced with a special bit pattern that forces the ARM into debug mode. • Unlimited number of software breakpoints available. • Hardware breakpoints (data accesses) are possible while debugging from RAM or ROM. • Triggered by particular address access. • Maximum of one hardware breakpoint at a time. (Green Hills Limitation) 7-21

  22. Software Breakpoints • Adding a software breakpoint takes one click! 7-22

  23. Hardware Breakpoints • Hardware breakpoints installed via entering address or symbol name, r/w/x. 7-23

  24. Debugging in a multi threaded operating environment – ThreadX Tools • Multi-2000 has a number of specific tools for debugging and analyzing ThreadX. 7-24

  25. ThreadX Tools 7-25

  26. ThreadX Tools 7-26

  27. Linking Files 7-27

  28. Introduction • The linker places text & data into the appropriate sections of memory, as defined by the • User-supplied section map, or • Default linker section map • Application can benefit by splitting the program into sections such that it will more readily support different types of memories. Factors include: • Speed of parts (performance requirements) • Cost & availability 7-28

  29. Linker Directives File • Major GHS supplied linker directives: 7-29

  30. Linker Directives File (cont.) • NETSilicon provided linker directives • Common linker attributes • align(expr) - Section will start on first expr-byte aligned address following previous section • pad(expr) - Linker will reserve expr bytes for this section in memory • ROM(expr) - Section becomes a ROMmable copy of expr. Section inherits the attributes and data of expr, while expr is modified to reserve address space only (as if it were all padding with no data) 7-30

  31. ROM and RAM Execution 7-31

  32. Basic RAM & ROM requirements for NET+OS • 512KB – 1MB Flash Recommended • Primarily for code storage • Code execution for low-end applications • 2MB – 8MB RAM Recommended • Data buffering for DMA channels • Thread stacks • Heap • Place holder for new image download • Code execution for higher-end applications 7-32

  33. System Memory Map 7-33

  34. System Memory Map • BSP provided memory map is designed with cache in mind. • Same map will work with or without cache. • Entire memory map configured using 2 control registers per chip select. • Address bit masking allows for multiple memory images – ideal for setting up cacheable regions. 7-34

  35. Relative application speed • FLASH memory typically 90-120ns read access time. • Can decrease access time to 35-50ns by leaving flash chip “on” all the time. • SDRAM typically 7-10ns access time. • Running from RAM is typically faster. 7-35

  36. Supporting FTP FLASH upgrade • FTP server must be running out of either Flash or RAM. • FLASH update is invoked by an FTP client requesting to “put” file of special keyword filename. • File is transferred to Net+ARM system memory buffer (RAM). • A subsequent procedure, running in RAM, burns Flash with this new image. • Running in RAM is the key to this step. 7-36

  37. Project Structure Note ramimagezip.bld is main project, including only subproject, linker. -> Also includes project options. -> Inherits additional options from a parent project. 7-37

  38. ramimagezip.bld - what it looks like #!build default: program :elxr_map_option=map :elxr_map_option=numeric_sort :postexec=gmemfile -s ramimagezip -o ram.bin :postexec=compress ram.bin ramimagezip.bin :postexec=bin2obj ramimagezip.bin .\zobjs\ramimagezip.o project.bld subproject ramimagezip.lx linker_file 7-38

  39. project.bld - contents Note the hierarchy - project.bld includes only source files and libraries. Conclusion - the same project.bld can be used with several programs. 7-39

  40. project.bld - what it looks like na1.lib library na2.lib library bsp.a library tcpip.a library tx.a library appconf.h include_file #!build default: subproject root.c C bsproot.c C dialog.c C decompress.c C reset.s assembly cont… 7-40

  41. 3 Ways to Run… rom romzip ramimagezip RAM* ROM ROM Boot Execution Application Execution RAM ROM RAM *Note - Executable downloaded with Debugger 7-41

  42. Run-time Physical Memory Mapping 0xFFFF FFFF Device Physical Address IGNORE FOR NOW 32-bit Internal Address Space 0x001F FFFF 0x021F FFFF CS0 (Flash) 0x0000 0000 0x0200 0000 Unmapped 0x00FF FFFF 0x00FF FFFF CS1 (RAM) 0x0000 0000 0x0000 0000 7-42

  43. ramimagezip Executable Location 0xFFFF FFFF IGNORE FOR NOW 32-bit Internal Address Space CS0 (Flash) Unmapped 0x00FF FFFF CS1 (RAM) Executable Location 0x0000 0000 7-43

  44. Memory Map - ramimagezip CS1(RAM) Top of Physical RAM Unused unknown until link Initialized r/w Data Constant Data Text (instructions) 0x0080 0000 .picbase Unused stack heap bss data Explicitly defined in linker file (ramimagezip.lx) unknown until link Data Section 0x0000 1000 .sdabase Vector Table 0x0000 0000 .pidbase 7-44

  45. rom.bld Executable Location IGNORE FOR NOW 32-bit Internal Address Space 0x02FF FFFF CS0 (Flash) 0x0200 0000 Unmapped Executable Location 0x00FF FFFF CS1 (RAM) 0x0000 0000 7-45

  46. Rom-based Memory Map - rom.bld Top of Physical Flash Unused CS0 (Flash) Initialized r/w Data Constant Data Text (instructions) 0x0200 0000 .picbase Top of Physical RAM Unused stack heap bss data CS1 (RAM) Data Section .sdabase 7-46 Vector Table 0x0000 0000 .pidbase

  47. ROM Compression - romzip.bld romzip is the small bootloader that will reside at beginning of Flash, uncompressed. -> It is also the parent project of ramimagezip.bld. 7-47

  48. romzip.bld - what it looks like #!build default: program :c_option=noasmwarn :elxr_map_option=numeric_sort :arm_option=bigendian :arm_cputype=arm7tm :object_dir=.\zobjs :driver_opts=-map entry=Reset_Handler_ROM :sourcedirs=.\..\..\..\bsp :sysincdirs=.\..\..\..\..\h :sysincdirs=.\..\..\..\..\h\threadx :defines=NET_OS :defines=ENABLE_FLASH_COMPRESSION :postexec=gmemfile -s romzip -o romzip.bin reset.s assembly decompress.c C .\..\loader.c C .\zobjs\ramimagezip.o object_file bsp.a library .\..\romzip.lx linker_file .\..\ramimagezip.bld program romzip.map Custom 7-48

  49. romzip.bld Executable Location Same as rom.bld IGNORE FOR NOW 32-bit Internal Address Space 0x02FF FFFF CS0 (Flash) 0x0200 0000 Unmapped Executable Location 0x00FF FFFF CS1 (RAM) 0x0000 0000 7-49

  50. Memory Map - romzip.bld Top of Physical Flash Unused CS0 (Flash) Initialized r/w Data Constant Data Text (instructions) Same as rom.bld 0x0200 0000 .picbase Top of Physical RAM Unused stack heap bss data CS1 (RAM) Data Section .sdabase 7-50 Vector Table 0x0000 0000 .pidbase

More Related