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.
Dear experts,
As far as I understand, the address 0x80000 (I'm using TI28377D) contains four-byte values: the "entry point symbol," which can be referred from the .map file. For example, the symbol name is _c_int00 @ 0x8378A.
In my project, my built .hex file does not contain this information, which prevents normal booting under standalone mode.
My question is: How can this symbol address be automatically embedded through the command line? (I have tried manually adding the symbol address in the hex file, and the operation was normal under standalone mode.)
According to the reference spru514, I have added the link option --rom_model, but the entry point symbol is still not embedded.
Here is the partial command I've used in the Makefile:
-m $(PROJECT_NAME).map -e _c_int00 --rom_model -o $(PROJECT_NAME).$(BINARY_SUFFIX)
Am I missing any commands?
Thanks,
C.C, Liu
Hi,
Let me gather more information on this. Shall get back to you.
Thanks
Aswin
Hello,
Please note that responses may be delayed due to the local holiday.
Thank you
ki
A hex file has no concept of a symbol, including the entry point symbol. Here is a rough, pseudo-code way of describing what a hex file contains. It contains a series of records. Each record contains this information: at <address> encode <length> <values>. There is no mechanism by which the entry point can be represented.
Thanks and regards,
-George
Hi George,
Thank you for your reply, but I am still confused about it.
For example, the .hex file below is built by TI example code. Line 2 indicates the start address (0x80000 - 0x80001) with the entry point address (0x82821, which is _c_int00 and shown in the .map file).
However, my own code does not show the start code (0x80000 - 0x80001 in words) like below. This omission causes my code to be unable to operate under standalone mode because it lacks the start code address.
After manually adding the start code address with the entry point symbol (as shown below at line 2), the code can operate under standalone mode. Therefore, I believe that including the start address with the entry point address is mandatory.
Additionally, in TI's example code, its makefile also contains commands to embed the entry point. After incorporating TI's commands into my project, the start address (0x80000 - 0x80001) still does not get generated.
Could you please confirm if my understanding is incorrect? If not, why does my .hex file not embed the start address?
Many thanks,
C.C, Liu
Hello,
For example, the .hex file below is built by TI example code.
Additionally, in TI's example code, its makefile also contains commands to embed the entry point.
Can you please show me where the .hex file and the makefile you mention are located? I will try to take a look at these on my side.
Hi Liu,
I talked with another expert and I think I know a way that should be able to place the symbol in the location you're designating. Instead of modifying the compiler options what you can do in your code is add a #pragma DATA_ALIGN and #pragma DATA_SECTION for the _c_init00 symbol to be allocated to the specific memory section you're designating. Then, you'll need to modify your linker command file to have an additional section for this symbol and its location in memory. As long as the _c_init00 variable is accessible globally, this should work (you may have to manually modify some files to be able to do this):
C source file example:
#pragma DATA_ALIGN(_c_init00, 2) #pragma DATA_SECTION(_c_init00, ".cust_sect")
Linker file example:
SECTIONS { codestart : > BEGIN .text : >> RAMD0 | RAMD1 | RAMLS0 | RAMLS1 | RAMLS2 | RAMLS3 .cinit : > RAMM0 .switch : > RAMM0 .reset : > RESET, TYPE = DSECT /* not used, */ .cust_sect : > FLASH0 ...
You can look at the example in libraries\communications\Ethernet\third_party\lwip\examples\enet_lwip\cm for an instance of this, with the startup_ccs.c and 2838x_flash_lnk_cm_lwip.cmd files.
Hello Amir,
Thank you for your reply, but my concern was not regarding the entry point symbol configuration, as it can already be found in the .map file.
My concern lies solely in how I can observe the start address 0x80000 carrying 2 words of the entry point symbol generated in the map file, ensuring that the leading code can operate normally under standalone mode.
Upon re-tracing the TI example code, I discovered an assembly file (for example, F2837xD_CodeStartBranch.asm) that should define the code starting point, as shown below.
The deficiency in my project is that I neglected to configure ".sect "codestart"". After adding this, my .hex file now contains the entry point address (_c_int00 @0x838BD) as shown in the .map file (please refer to the screenshot below).
What I did was add the following assembly code to my .c file. Now, the code can operate normally in standalone mode.
Regards,
C.C, Liu
The deficiency in my project is that I neglected to configure ".sect "codestart"". After adding this, my .hex file now contains the entry point address (_c_int00 @0x838BD) as shown in the .map file (please refer to the screenshot below).
What I did was add the following assembly code to my .c file. Now, the code can operate normally in standalone mode.
So is your query resolved or do you still have a question?