This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
I am working with tiva c series on generating a motorola format image in its 32 bit address form and have had issues. I have tried the following compiler versions without success:
- TI v5.1.6
- TI v5.1.9
- TI v5.1.10
The generated motorola formatted hex files do not match with byte by byte comparison (taking into account ascii formatted bytes in the motorola format and the binary bytes being in their raw format, etc) of the data bytes with a generated binary file and the hex file is smaller than the binary file. Is there a reason for such a failure in the hex conversion? Is there a setting that I am missing?
Thank you in advance for your help.
The hex utility is described in the chapter titled Hex Conversion Utility Description in the ARM assembly language tools manual. The section titled Motorola Exorciser Object Format gives the details of hex utility output for that format. Perhaps this will help you understand what you see.
Thanks and regards,
-George
Is there any way you could show a small portion of code or data that has not converted correctly? Maybe the first 20 bytes of a function, or data table. Please describe how you developed the view of the object code or data prior to conversion to Motorola format. I usually use the Unix command od. But there are many other ways to do it. In addition, show how the hex utility is being invoked. If that includes a command file, show the contents of that file. I am unlikely to figure this out based on that information alone, but it should advance the issue.
Thanks and regards,
-George
After carefully parsing it out, you can see that both of the memory blocks shown start at target address 0x00018000. The non-working block shows contents of 0x182d2753 at that address. The working block shows 0x18190020. Let's focus on this one difference. It is probably typical. I presume 0x18190020 is the correct contents. I don't know anything about the vector table. What is contained there? An address? Or an instruction? What could possibly explain this difference? Does it make sense to disassemble the original executable (usually .out) file and see what it shows at this address?
Thanks and regards,
-George
Please attach the linker map file. This file is usually the same name as the executable .out file, but with the extension .map instead. That file will show me what section is loaded at address 0x00018000.
Thanks and regards,
-George
What is the value of the symbol __STACK_TOP? Is it possible that it could change between builds?
Thanks and regards,
-George