TMS320F28384S: hex2000 tool does not split memory blocks at 128[bit] aligned addresses

Hi Inno,

This is a known issue and the big fix will be available in future releases.

For now, will you be able to limit the length of the memory sections to 0xFFF0 in the linker command file?  This may need you to split the memory entries in the linker command file.

Please take a look at this:  https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/964813/compiler-tms320f28386d-hex2000-output-file-address-not-fit-alignment-128-bits

Thanks and regards,
Vamsi

Hello Vamsi,

First of all thank you very much for the quick reply. It seems that this bug is known for over a year and not yet been handled by the development team. This one has quite some priority for us…

However, I am not sure that the solution in that post you mentioned above does help us.

First of all, allow me to ask one question regarding Input Sections. Inside our file Terminal.c we have several arrays that belong to the .const input section like s_DriveCommands, s_ErrList or c_DriveSpecialCommands (you can find those arrays in the picture of my first post). Is each of the arrays considered as a seperate .const input section element of the Terminal.obj file during the linker process, or are all arrays are being merged together as one .const input section of the file Terminal.obj and handled by the linker as one input section? When I look at the diagram of the following website, it seems that all data (arrays, structures etc…) of a certain file, that belongs to an input section .const, is being considered as one input section. See here:

https://software-dl.ti.com/ccs/esd/documents/sdto_cgt_Linker-Command-File-Primer.html#diagram

This is important for me to understand, when looking at the following statement from George in the other post ( https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/964813/compiler-tms320f28386d-hex2000-output-file-address-not-fit-alignment-128-bits ):

“When an output section is too large for the first memory range, it is split and allocation continues into the second memory range.  The splitting always occurs on input section boundaries.  Therefore, a single function is never split.”

Now let me explain why I believe that we may not be able to use the approach, splitting the physical memory in chunks of size 0xFFF8. If I look at all .const data inside file Terminal.c, you can see that we already exceed in total the length of 0xFFF8. Therefore my question above, if all arrays are being considered as one input section of a file or if each arrays is considered separately.

But even the single array s_DriveCommands is about to exceed the size of 0xFFF8 (it has currently the size 0xF68E) and I am afraid that the so-called input section boundaries, which are never split, exceed the 0xFFF8 size and therefore never fit in those chunks of physical memory that has been suggested to implement in the linker command file.

Is it possible that the relatively big size of our arrays causes a conflict when trying to apply the workaround explained in the other post?

Thanks,

Inno

Hi Inno,

I will ask George to help you further.

Thanks and regards,
Vamsi

This ...

inno said:

the single array s_DriveCommands is about to exceed the size of 0xFFF8 (it has currently the size 0xF68E) and I am afraid that the so-called input section boundaries, which are never split, exceed the 0xFFF8 size and therefore never fit

... is a legitimate concern.  You have 0xfff8-0xf68e = 0x96a (about 2400 words) to go.  So, maybe you'll never hit the limit.  But, if you do, then the linker workaround fails.

At that point, you have to consider changes you can make in the C code which cause s_DriveCommands to be smaller.  My guess is that this is an array of structures.  Maybe some of the fields in the structure can be changed to bit fields.  Or, maybe change some fields to 8-bit wide values that are read and written with techniques described in the article Byte Accesses with the C28x CPU.  Or, other ideas along these lines.

Thanks and regards,

-George

Hi George,

It is indeed an array of structures and quite a huge amount of it is an ASCII description of a serial command, which resides inside that array. So it means that we have to either reduce the size of the array (array of structures) or I write an own tool, which re-arranges the memory address/ length / data information inside the *.hex file to match the 128[bits] alignment. So basically an own written "correction tool" (which is a bit risky because every mistake in that tool ruins the firmware image).

I have 2 more general questions. The first question is about input sections. Inside our source file Terminal.c there are several structures, which all belong to the input section .const. The linker forms output sections from input sections according to the following picture:

My question is, if each individual array inside our file represents one green square in the above picture (so there can be several squares coming out of one .obj file going to the same osX output section) or if all arrays, which belongs to input section .const of that particular file, are first assembled together to one common input section .const before the linker forms it to an output section?

The second question is, how long do you think will it take the TI development team to fix the bug and release a new hex2000 version in one of the upcoming C2000 compiler/toolchain versions? Can you make an estimation about that?

Thanks,

Inno

Hi George,

Thank you for the explanation. Everything is clear now. I believe we would like to leave everything as it is (so we won't use your proposed workaround modifying the linke command file).

I started writing a C#/.NET tool, which goes through the *.hex binary file and detects any non-128[bit] aligned address. I will re-arrange the data blocks inside the *.hex binary file a bit.

What I will do is the following (I refer to the last picture in my 1st post):

I will take shorten block 6 by 6 words.
I will also shorten block 7 by 2 words (if 2 words are available inside that block).
I will squeeze in a new data block between block 6 and 7 with 8 words (6 words coming from block 6 and 2 from block 7). Of course I must modify the word-length of block 6 (reduce by 6) and 7 (reduce by 2). I also have to modify the address of block 7 (increase by 2).
That new data block has the word length of 8 and the address of 0x97FF8.

Thanks again for your support.

-Inno