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
"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.