Hi all
I would like to link a plain binary file (parameter.bin) to a specific location in the flash using a scatter file.
If i had a compiled object file (parameter.o) file, it would be easy, but that's not the way i want to do it:
LR_ROM_BL ROM_LOAD_BASE ROM_BOOTLOADER_SIZE { ER_ROM_BL ROM_LOAD_BASE (ROM_BOOTLOADER_SIZE) { ; load address = execution address parameters.o } }
I would like to do it like this:
LR_ROM_BL ROM_LOAD_BASE ROM_BOOTLOADER_SIZE { ER_ROM_BL ROM_LOAD_BASE (ROM_BOOTLOADER_SIZE) { ; load address = execution address parameter.bin } }
But when I add parameter.bin to my uVision Project as an object file, i get the message:
..\out\basisprojekt_stm32f103neu.axf: error: L6007U: Could not recognize the format of file ..\out\parameter.bin.
And when I dont add Parameter.bin to my uVision Projekt, i get:
..\misc\stm32f103x_md.sct(67): warning: L6314W: No section matches pattern parameter.bin(RO).
Any Idea? Regards, Martin
The goal of a linker is to link object files - not binary files.
So a simple method would be to convert your bin data to a named C array in a separate source file, and link that array to that address range.
ER_ROM_BL ROM_LOAD_BASE (ROM_BOOTLOADER_SIZE) { ; load address = execution address parameter.bin }
Has the linker manual told you this is possible? Hmm, how interesting.
I have done this with other linkers (if i remember correctly it was the gnu linker), its a matter of the linkers capability and scatter file syntax. Unfortunately I cant find anything about that in the Linker Manual...
Create an assembler file containing a data section and import the binary using the INCBIN directive (infocenter.arm.com/.../armasm_caccaghf.htm). Place this data section anywhere according to your scatter loading file.
The linker doesn't care whether the bytes represent actual data or code.
Regards Marcus http://www.doulos.com/arm/
Thats a smart idea, thanks Marcus:
AREA parameter, CODE, READONLY INCBIN parameter.bin END
Unfotunately, the linker kicks out the section because it thinks its unused:
Removing parameterinclude.o(parmeter), (1428 bytes).
Use +FIRST (or +LAST for that matter) in the scatter file. -- Marcus
hmm, it still removing the section with the following in the scatter file:
.ANY(bootloader, +Last)
upps, sorry, its
.ANY(parameter, +Last)
Ok, it works now using
AREA parameter, CODE, READONLY, PREINIT_ARRAY
in the assembly file.
Im still disappointed that its not possible using only the linker file.
Thanks for your help!
"Im still disappointed that its not possible using only the linker file."
Why? Why need many ways to do something?
Because of the way we want to work: One team developping the bootloader, the other team developping the firmware. Now the firmware team has to be aware of the bootloader, even during early stage of developping.
But its not a huge disadvantage, so dont worry...
Sorry but how your team works doesn't really make a difference here. Including a binary file from an assembly file or from the scatter file or having a preprocessor program convert bin->C array is still just build steps resulting in the same end result.
dont want to get into discussion of our worflow here. so never mind... thanks & regards, martin
Of course - that would require that you do have an argument that really did manage to show a relevant difference. That it is a real inconvenience for the team that you need to select one build alternative instead of another. But all three alternatives we have discussed requires a linker with scatter-file support. So anyone building the final binary would then have access to the linker.
And the fourth alternative would be to build two hex files separately and either load them separately or merge them. Obivously a step that is performed after the normal build, so the capabilities of the linker wouldn't matter. This is the alternative I use for factory releases - merging a boot loader, an optional configuration sector and an application into a single file that the factory then programs. For inhouse use, people normally plays with boot loader or application individually.