04-07-2018 04:19 AM
Dear Community Users,
Has anyone encounter the following problem (inconsistent bin. file after using mb-objcopy) ? I ran the example freertos application on Vivado SDK 2017.4, and I converted the elf file to bin file by using mb-objcopy. After this, I examined the bin content and the default memory content. The last element of the bin file is 00E1F505 ( or 05f5e100), but the last element of the default memory file is not 05f5e100. There are lots of unclear values following 05f5e100 in the memory content. It is particularly strange that there are lots of "a5a5a5a5"! Did anyone has the same issue? Any suggestions would be greatly appreciated!
Fig. BIN file
Fig. Memory Contents
04-07-2018 09:30 AM
I don't know about your particular problem, but you might want to take a look at your map file or linkerscript to see what else those other memory locations are used for. E.g., stack, heap, bss, etc.
04-08-2018 04:56 AM
Thanks a lot for the reply and suggestion. When I ran the sample application on SDK and the OS platform is standalone, the memory content is consistent with what I have observed from the BIN file, and at least under this situation, there won't be so many "a5a5a5a5" values. However, when I ran the SDK application and the freertos901_xilinx is chosen as the OS platform, the memory content looked very weird. (Both cases use the same processor (Microblaze) and the same hardware exported from Vivado.) I am curious if anyone has ran into the same situation.