Embedded RealTime Systems Lecture Debug Monitor Program loading
Embedded Real-Time Systems Lecture: Debug Monitor, Program loading and initialization Dimitris Metafas, Ph. D.
1. Debugging of Embedded Systems
Debugging of Embedded Systems n Debugging of embedded systems is hard for a number of reasons: n n n Usually no terminal or display Programs tightly coupled to OS Timing sensitive functionality Absence of Memory protection Side effects of concurrency 3
Semi hosting n n n ARM target communicates I/O requests made in the application code up to the host computer running the debugger Can exploit libraries on the host to obtain the invoked library functionality Cause a software interrupt (SWI) to occur 4
Debug Monitor n n n Debug Monitor provides n Low level C library n Debugging environment ARM Debug Monitor is called Angel n Variable sized packet based communication with host n Support for external device drivers, e. g. , Ethernet When the X board boots it loads the Debug Monitor from the Flash memory (“bootstrapping”) 5
Angel bootstrapping n Goes through a system initialization phase – “bootstrapping” n n n n n “Level 0” bootstrapping – basic runtime initialization and loading Check to see if the processor is in 32 bit mode Branches to the beginning of ROM Checks RAM size Loads ROM content into RAM Initializes IRQ and FIQ handlers Initializes and clears the debug channel Initializes status LEDs, if any Finally, it enables interrupts 6
Memory map of Angel 0 x 0000 0 x 0004 Interrupt 0 x 0020 0 x 0400 0 x 0500 0 x 0600 0 x 0700 0 x 0800 0 x 1000 0 x 2000 0 x 8000 CPU reset vector. . . 0 x 1 c CPU undefined instruction. . . CPU Fast Vector ~1 K Bytes for FIQ and FIQ mode stack 256 bytes for IRQ mode stack 256 bytes for Undefined mode stack 256 bytes for Abort mode stack 256 bytes for SVC mode stack Debug monitor private workspace Free for user supplied Debug Monitor Floating Point Emulation Space Application Space 7
Angel SWIs SWI_Write. C (0) SWI_Write 0(2) SWI_Read. C(4) SWI_Exit (0 x 11) SWI_Enter. OS (0 x 16) SWI_Get. Errno (0 x 60) SWI_Clock (0 x 61) SWI_Time (0 x 63) SWI_Remove (0 x 64) SWI_Rename (0 x 65) SWI_Open (0 x 66) SWI_Close (0 x 68) SWI_Write (0 x 69) SWI_Read (0 x 6 a) SWI_Seek (0 x 6 b) SWI_Flen (0 x 6 c) SWI_Install. Handler(0 x 70) Write a byte to the debug channel Write the null terminated string to debug channel Read a byte from the debug channel Halt emulation this is how a program exits Put the processor in supervisor mode Returns (r 0) the value of the C library errno variable Return the number of centi seconds Return the number of secs since Jan. 1, 1970 Deletes the file named by pointer in r 0 Renames a file Open file (or device) Close a file (or device) Read a file Write a file Seek to a specific location in a file Returns length of the file object installs a handler for a hardware exception 8
Debug Monitor Program n n Provides capability to n Setup hardware on startup n Load and run programs n Debug code n Support breakpoints n Minimal OS functionality Many embedded systems are just n Monitor + application n 1 timer, I/O (e. g. , keypad, switches, LED, LCD) 9
Example system RAM Load and start user program User application Monitor local variables PC stack SWIs so user application can communicate with Monitor 10
Debugging Embedded Systems JTAG n n n Joint Test Action Group (JTAG) Extensive debugging and diagnostics Uses a small set of test pins Uses boundary scanning n Allows you to control device inputs n Observes data at device outputs n Independent of application logic During testing, I/O signals enter and leave chip under test through the boundary scan cells n The scan path circumvents the normal inputs and provides direct control of the device IC vendors need to modify ICs to add n Registers for each signal pin n Scan path connecting all registers n Control circuitry 11
2. Program Loading and Initialization
Compiler, Assembler, Linker n Compilers and assemblers generate re locatable object files n n n References to external symbols are not resolved Compilers generate object files in which code starts at address 0 Cannot execute a compiler produced object file Executable files are created from individual object files and libraries through the linking process Linker performs two tasks n n Symbol resolution: Object files define and reference symbols, linker tries to resolve each symbol reference with one symbol definition Relocation: Linker tries to relocate code and data from different object files so that different sections start at different addresses and all the references are updated 13
Linking models n Different kinds of linking models n Static: Set of object files, system libraries and library archives are statically bound, references are resolved, and a self-contained executable file is created n n Problem: If multiple programs are running on the processor simultaneously, and they require some common library module (say, printf. o), multiple copies of this common module are included in the executable file and loaded into memory (waste of memory!) Dynamic: Set of object files, libraries, system shared resources and other shared libraries are linked together to create an executable file n n When this executable is loaded, other shared resources and dynamic libraries must be made available in the system for the program to run successfully If multiple programs running on a processor need the same object module, only one copy of the module needs to be loaded in the memory 14
Example int z; extern int square(int); int main() { int x, y; int sum(int, int); x=10; y=5; x=square(x); y=square(y); z=sum(x, y); } static int sum(int x, int y) { int u; u=x+y; return u; } main. c main $a compiler . text 0 x 0000: 0 x 00000004: 0 x 00000008: 0 x 0000000 c: 0 x 00000010: 0 x 00000014: 0 x 00000018: 0 x 0000001 c: 0 x 00000020: 0 x 00000024: 0 x 00000028: 0 x 0000002 c: 0 x 00000030: 0 x 00000034: 0 x 00000038: 0 x 0000003 c: sum 0 x 00000040: 0 x 00000044: 0 x 00000048: $d 0 x 0000004 c: STMFD r 13!, {r 3 -r 5, r 14} MOV r 4, #0 xa MOV r 5, #5 MOV r 0, r 4 BL square MOV r 4, r 0 MOV r 0, r 5 BL square MOV r 5, r 0 MOV r 1, r 5 MOV r 0, r 4 BL sum ; 0 x 40 LDR r 1, 0 x 4 c STR r 0, [r 1, #0] MOV r 0, #0 LDMFD r 13!, {r 3 -r 5, pc} MOV ADD MOV r 2, r 0, r 2, r 1 pc, r 14 main. o DCD 0 15 int square(int x) { return x*x; } square. c compiler square $a. text 0 x 0000: MOV 0 x 00000004: MUL 0 x 00000008: MOV square. o r 1, r 0, r 1 pc, r 14
Example (cont) main $a. text sum 0 x 000080 a 8: 0 x 000080 ac: 0 x 000080 b 0: 0 x 000080 b 4: 0 x 000080 b 8: 0 x 000080 bc: 0 x 000080 c 0: 0 x 000080 c 4: 0 x 000080 c 8: 0 x 000080 cc: 0 x 000080 d 0: 0 x 000080 d 4: 0 x 000080 d 8: 0 x 000080 dc: 0 x 000080 e 0: 0 x 000080 e 4: STMFD r 13!, {r 3 -r 5, r 14} MOV r 4, #0 xa MOV r 5, #5 MOV r 0, r 4 BL square ; 0 x 80 f 8 MOV r 4, r 0 MOV r 0, r 5 BL square ; 0 x 80 f 8 MOV r 5, r 0 MOV r 1, r 5 MOV r 0, r 4 BL sum ; 0 x 80 e 8 LDR r 1, 0 x 80 f 4 STR r 0, [r 1, #0] MOV r 0, #0 LDMFD r 13!, {r 3 -r 5, pc} 0 x 000080 e 8: MOV 0 x 000080 ec: ADD 0 x 000080 f 0: MOV r 2, r 0, r 2, r 1 pc, r 14 square $a. text 0 x 000080 f 8: MOV 0 x 000080 fc: MUL 0 x 00008100: MOV r 1, r 0, r 1 pc, r 14 linker merges the code from separate object files into a single executable file linker adds the actual address of symbol square linker relocates the code to a different memory location 16
Kinds of Object files n n Three main types of object files Re-locatable file: Code and data suitable for linking with other object files to create an executable or a shared object file Executable file: Program suitable for execution Shared object file: Code and data suitable for linking in two contexts n First, the link editor may process it with other re locatable and shared object files to create another object file n Second, the dynamic linker combines it with an executable file and other shared objects to create a process image 17
Executable and Linkable Format n n n Object files need to be in a specific format to facilitate linking and loading Executable and Linkable Format (ELF) is the popular format of an object file Supported by many vendors and tools n n n Diverse processors, multiple data encodings and multiple classes of machines ELF specifies the layout of the object files and not the contents of code or data ELF Header n Beginning of ELF file n Holds a road map of file’s organization n How to interpret the file, independent of the processor Sections n Object file information for the linking view n Instructions, data, symbol table, relocation information, etc. Program header table n Tells the system how to create a process image n Files used to build a process image (execute a program) must have a program header table n Re locatable files do not need one 18
ELF header #define EI_NIDENT 16 typedef struct { unsigned char e_ident[EI_NIDENT]; // file info Elf 32_Half e_type; // type of file Elf 32_Half e_machine; // target processor Elf 32_Word e_version; // version # Elf 32_Addr e_entry; // program entry point Elf 32_Off e_phoff; // offset of program header Elf 32_Off e_shoff; // offset of section header table Elf 32_Word e_flags; // processor-specific flags Elf 32_Half e_ehsize; // ELF header’s size Elf 32_Half e_phentsize; // entry size in pgm header tbl Elf 32_Half e_phnum; // # of entries in pgm header Elf 32_Half e_shentsize; // entry size in sec header tbl Elf 32_Half e_shnum; // # of entries in sec header tbl Elf 32_Half e_shstrndx; // sec header tbl index of str tbl } Elf 32_Ehdr; 19
Loading an AXF n n n More than one format are used for the ARM. AXF is a specialized version of ELF. Read the file from host n Loader uses the SWI_Open and SWI_Read Monitor system calls Parse the header to determine the size of the image and its n Starting Location n Image Base Read the executable’s text and data segments into RAM n Image Readonly size (text or code segment) n Image Read. Write size (initialized data segment) Zero init the un initialized data Determine the starting PC 20
Starting a Program n n To get to main() takes hundreds of instructions! n In a modern OS, it can take several thousands of instructions! n Why? Because the C compiler generates code for a number of setup routines before the call to main(). n These setup routines handle the stack, data segments, heap and other miscellaneous functions. What about assembly code? n If the assembly code interfaces to C code and the ENTRY point is the C function main(), then the C compiler will generate the setup code n But, if the entire program is written in assembly OR there is no C function called main(), then the setup code is not generated. 21
REMAP (1) n n n One critical thing in an embedded ARM application is the memory map n Following reset, the processor starts to fetch instructions from 0 x 0 n There needs to be some executable code at 0 x 0 n Requires ROM to be present, at least initially, at 0 x 0 Simplest thing to do would be to put the application in ROM at 0 x 0 n Then, at every reset, the application could start executing directly Why is this not a good idea? n ROM is typically narrow (8 16 bits) n ROM is typically slow (more wait states involved in access) – future class n Can slow down exception handling and interrupt handling n Also, a ROM hosted vector table cannot be modified 22
REMAP (2) n n n Locating RAM at 0 x 0? For the sake of the vector table and interrupt handlers, it would be better if the kind of memory at 0 x 0 was RAM So, what do we need to worry about then? n Well, when the board powers up, there is nothing in RAM! n No instruction to execute initially at 0 x 0 The magic that needs to happen then is n At board power up, ROM should be located at 0 x 0 n At normal execution time, RAM should be located at 0 x 0 n Done through a special memory mapped (REMAP) register which is overwritten Sequence n Power up and fetch reset vector at 0 x 0 (still in ROM) n Execute reset vector – causes jump to next ROM instruction n Write to the special REMAP register n Complete rest of initialization 23
- Slides: 23