Procedure to download code in Flash Memory_问答_开发者

I am new to Embedded field. One doubt came up in my mind ab开发者_Python百科out hex file downloading: As output of the linker and locator is a binary file having various sections as .text,.bss,.data etc. and .text resides in Flash, .bss goes to RAM, .data goes to RAM ... so my question is that

how .bss and .data are written to RAM as i am using FLASH Loader for burning my program onto flash.
Is there any index kind of thing in the final binary which discriminates between .text and .bss segments.
Is there any utility in the linker/locator which converts our simple binary into hex format.
How can I discriminate between .text and .bss from the contents of hex file?

Thanks in advance. Please help.

1.) how .bss and .data are written to RAM as i am using FLASH Loader for burning my program onto flash?

Code, constant data and initialized data are all written to FLASH. At runtime, initialized data is copied to bss during startup. Constant data is usually accessed directly (you declare it with the "const" keyword).

2.) Is there any index kind of thing in the final binary which discriminates between .text and .bss segments?

I think you mean by "binary" the linker output. This is usually referred to as an object file and is different from a binary image. The object file includes all code, data, symbol, debug information and memory addresses. For the GCC tool chain, the linker output is usually an .elf file.

Your linker uses a "link script" or other definition file to locate the various segments at the appropriate memory addresses. Your tool chain should have docs on how to change that.

3.) Is there any utility in the linker/locator which converts our simple binary into hex format?

The "objcopy" utility will read linker output and can write output files in a variety of formats, including Intel-hex. For human readable output see "objdump".

4.) How can I discriminate between .text and .bss from the contents of hex file?

By memory address. GCC uses the "initialized data" segment for data which is copied to the bss. It is located according to your linker script.

Intel-hex format: http://en.wikipedia.org/wiki/Intel_HEX

GCC: http://gcc.gnu.org/onlinedocs/

Your programming tools just write the program image (hex or binary file) into Flash, at the specified address.

When the compiler compiles the program, it adds information (look-up tables) containing information about the .bss and .data etc into the hex file, along with some C start-up code. The C start-up code, which runs before the C main() function begins, is responsible for initialising .bss and .data according to the information in the look-up tables in Flash memory. Typically, that means:

Initialising .bss to zeros.
Copying initialisation values for .data from the Flash memory into the appropriate locations in RAM.
- (On some platforms, the initialisation values might even be stored compressed to save space in Flash, and the start-up code decompresses it as it writes it to RAM).

On some platforms, you might want to run code in RAM, for various reasons. The C start-up code can also copy code from Flash to RAM in a similar way.

The C start-up code can also do other essential things:

Initialise stack(s) and initial stack pointer
Initialise heap (if your program uses it)
Set some essential processor configuration, such as processor operating mode, clock speeds, Flash wait states, memory management unit, etc

Typically these issues are solved by the embedded tools you use to manage the target device.

For small embedded devices (less than 16K to 128K of RAM and ROM/NVRAM), code executes directly from NVRAM. The initialization code copies initialized data to RAM, perhaps decompressing it, and initializes uninitialized RAM, usually by clearing it. The locator is responsible for making all data references access the proper target addresses and not the address of ROM data.

Large embedded devices run much faster than NVRAM, so they tend to be implemented where NVRAM content (code plus data) is copied from NVRAM to RAM for execution.

To answer your other points:

2) The final binary is carefully structured to distinguish between program sections. There are many different file formats. See the corresponding Wikipedia article about the format for details.

3) You many not need to convert to hex format, though that depends on your target loader. For example, U-Boot based systems support kermit file transfers of the binary data.

4) See 2).