Hi, I am having a difficulty using the HEX55.exe program from TI. My situation is that I have a program that builds fine and produces a good binary. However I recently commented some code out and suddenly the binary produced has one byte more in the .text section than the section header says it has! It seems to be a bug in HEX55.
I am using some in line asm so I suspected that might be causing section misalignment. I tried adding NOPs and there was no change.
I've tried reordering the sections, this is how I narrowed the problem down to the .text section.
I have had another similar problem with the HEX55 program. If a section is not listed explicitly in the linker command file, it links OK but the hex55 utility just dumps the missing section at the end of the binary output file with no header. I've checked for missing sections in the linker command file and as far as I can see they are all there.
Has anyone got any ideas or tricks to narrow down the problem and/or solve it?
Are you sure that there is something wrong with the hex utility? Have you checked the .map file generated by the linker to verify whether or not the .text section actually changed sizes? If you're using optimization then it might be hard to know what effects you might cause by adding in a chunk of code somewhere.
I think there's an option that you can have hex55.exe produce an output memory map file. I'd start there to see what it's putting in your image and maybe get some new insight into the problem.
Below is a part of the map file from the linker and the binary conversion report from the hex55 program. As you can see the .text section is reported as 0x7025 in both. When I open (using a hex editor) the hex55 output file (imaginatively named main.bin ;-) and count the bytes in the section, I find that there is actually 0x7026 bytes before the next section header. The last byte (the extra one) is the same as the second to last (the real last byte).
I would suspect that there is some bad inline assembly or something like that but the build works properly until I remove a section of C code from my main.c file. Th C code in itself is fairly innocuous and in the form shown below can never be executed anyway (my work around for this problem).
item = 0; if ((item & 0xFF) == 0x2D) //if we got an r then reset in USB mode { printm("Resetting\n"); printu("Resetting\n"); queue_addback(&D2401_in_queue, CMD_Byte_Command | BYTE_CMD_Reset_for_USB_Boot); } else if ((item & 0xFF) == 0x1B) //if we got an s then show the list states { ghost_state(); }
All this is with the optimiser turned off. ie no -ox in the command line.
Thanks for your advice, it helped to clarify my thinking about how to track the problem down. Anybody have any more ideas?
Felix
****************************************************************************** TMS320C55x COFF Linker PC Version 2.56
****************************************************************************** >> Linked Wed Sep 29 10:08:51 2004
OUTPUT FILE NAME: ENTRY POINT SYMBOL: "_c_int00" address: 0001a0b2
MEMORY CONFIGURATION
name origin length used attr fill (bytes) (bytes) (bytes) ---------------------- -------- --------- -------- ----
Haven't read your post deeply but I noticed that Section Header Structure contains Section size in words (Byte 16-19) according A.4 in TMS320C54x Assembly Language Tools User's Guide (SPRU102f) and Section size in Bytes (16-19) according to A.4 in TMS320C55x Assembly Language Tools User's Guide (SPRU280d). May there is a bug in the description and the Sections are word aligned ? Hence each section must have even bytes and if not it's fitted (e.g. by copying the last one ?). During load that doesn't matter.
I haven't looked at your post in depth either, but remember the C55xx doesn't have 8-bit byte support. The smallest unit is a 16-bit word, i.e., char = 16 bits.
I got caught by this when I defined an assembly language block with an 8-bit value in it. All the C references turned out to be off by a byte, which had some interesting effects.
Scott, the memory of the 55xx is complicated by the fact that data is 16 bit addressed and code is 8 bit addressed in the same memory. Code is made up of 8 bit bytes. In this case the problem is with the code section so it will be something to do with the 8bit bytes.
Wolfgang, I'm not sure about the 54xx but the 55xx definitely has the sections in bytes. I have it working after all so I am sure of this. On tricky thing that I just remembered is that the code sections are aligned on even byte addresses in the boot table even though they are not aligned so in memory. This means that the hex55 utility stuffs bytes at the beginning or end of the section as required to make the section begin on even byte addresses and end on odd. I think this is so the boot table can be read in 16 bit chunks and code and data sections can be mixed. The boot loader discards the stuffed bytes depending on the start address of the section and the section length. (SPRA375D Using the Boot loader - Page 19)
So suspecting this to be the problem... I checked the section start address for .text (see paste from .bxp file in earlier mail) and it shows that the section starts at an even address. It is an odd length so it will end on an even address. So... byte (octet) stuffing is neccessary. Here is the problem!
Logically, the byte count of the section must not include the stuffed bytes because the boot loader uses this to determine whether to strip bytes off the end. eg "IF address + length = odd number THEN strip last byte".
Thanks for letting me bounce this off you all, hopefully this is the solution.
I've written a custom boot loader and some scripts for custom processing of the boot table files so now I better correct them all!
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.