So, last but not least for other collegues wich might be also fighting with xMega and GCC linker ( and it's pore/rare documentation ). so it's a way but also not really safe for a lot of products. my ATxMega due to the AVR:102 Bug once again also special thanks to you, you broght me to the idea to try around avrobj-copy and formats, so your hint was not 100% solving the linker error but it helped to find a solution i know your solution because i did that also in the past, it has the clear disadvantage that it's not really comfortable, you need a target system connected, to care about the fuses ( correct target sys. Thank you all special thanks to your post from : 05:43 PM, it was one i could really follow and understand, but even soo, it didn't work w. Hi all, Halleluya it works !javascript:emoticon(':D')
HOW TO LOAD BOOT.ELF CODE
:103860000E94361C0C943B1C0C94001C8FEF87BBF1Īs I hope you can see this contains two virtually identical copies of the same thing - one "app" linked at 0x0000 and one boot loader linked at 0x3800īTW 8AEA = LDI R24,0xAA, 85E5 = LDI R24,0x55 (the difference between the "two programs").ĮDIT: (*) just realised that the initial Ttext=0x3800 was completely pointless (unless I planned to use the boootloader in isolation), I obviously set the actual boot code location with the later -Wl,-section-start=.boot=0x3800 in fact as the original 0x3800 location was lost in the elf->bin translation. I then made a one line change to the source that was now going to be my "application" (0xAA not 0x55): boot and the readelf output confirms that worked. data I chose to rename the section to be. Name Type Addr Off Size ES Flg Lk Inf Al Start of section headers: 208 (bytes into file) Start of program headers: 0 (bytes into file) data=.boot,contents,alloc,load,readonly,data -I binary -O elf32-avr boot.bin boot.o
0 kommentar(er)
