- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Hello,
We want to download an own-written flash application over SCI8 interface to the TMS320F28384S CPU1 core and program that flash application via the C2000 flash API inside the CPU1 flash memory. So basically something that the C2000Ware flash_kernel example project does. Note that the flash API requires a 128[bit] aligned address when accessing the flash, otherwise the flash programming results in an error.
The hex2000 tool creates a binary-file in the TI boot-table format for us:
Unfortunately, the length information inside that binary file is just 16[bit] wide, see here marked in red:
We have quite big arrays/structures inside our application firmware, which are initialized by the .const output section:
Unfortunately, the hex2000 tool does not split the output section .const at a 128[bit] aligned address. I verified that with an own written PC tool, which evaluates the flash address and length information inside the binary file, generated by the hex2000 tool, and writes the data into a text file. Please look how the boot-table binary is being constructed in terms of flash address and length information, especially block 6 & 7 holding .const output section data:
You can see in the map file, that the array c_DriveSpecialCommands[] is being the one, that crosses the block numbers 6 & 7 in the previous picture. That array is declared as follows:
EXTERN const struct SpecialCMDList c_DriveSpecialCommands[] INIT_VAR(=DRV_SPECIAL_COMMANDS_TABLE);
So trying to program data at address0x97FFE results in an error of the flash API program function.
Is there a way to instruct the hex2000 tool, splitting output sections at a 128[bit] aligned address? If not, what other options do we have to avoid such problems?
Thanks,
Inno
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 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
