arm-none-eabi-objcopy.exe generates wrong intel hex file
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| GNU Arm Embedded Toolchain |
New
|
Undecided
|
Thomas Preud'homme | ||
Bug Description
When calling
arm-none-
the resulting intel hex file contains records of type 2 ("Extended Segment Address"). This is inappropriate for the linar address space of the ARM architecture. Some tools don't process hex files containing these records.
Instead records of type 4 (="Extended Linear Address") should be generated.
Example for wrong out.hex:
:10FFC000B81A00
:10FFD0000146F9
:10FFE0009B0066
:10FFF000FB7901
:020000021000EC <-- Error
:100000001B019B
:1000100013461B
:10002000564913
:100030009A80FA
:10004000303310
Desired output:
:20FFC000B81A00
:20FFE0009B0066
:020000040001F9
:200000001B019B
:20002000564913
:20004000303310
---
Version: GNU objcopy (GNU Tools for ARM Embedded Processors) 2.24
Host: Microsoft Windows 8.1
| Thomas Preud'homme (thomas-preudhomme) wrote | #1 |
| Changed in gcc-arm-embedded: | |
| assignee: | nobody → Thomas Preud'homme (thomas-preudhomme) |
Hi Ubogensperger,
I believe you are experiencing the same issue as described by Panos in [1]. If that is so, you are the second person reporting the problem. I will open an internal ticket to look at this but I cannot give you any timeline of when this could be fixed. Could you give us an example input file for us to reproduce the issue? If not, would you be willing to test a patch to solve the issue?
[1] https:/
Best regards.