Hi,
I am using CodeSourcery (v 4.6.1) bare-metal (arm-none-eabi) to build an application on Windows. When I try to load the executable (simulator or device) I see that only the labels get loaded but none of the data or text. I am able to load the same executable if I use CCS v 5.0.3 correctly. I tried some applications that were built using the same version of the tool-chain and options on Linux and they seem to load correctly.
Is there some flag that need to be enabled on the windows version for CCS5.1 to work?
Regards,
Sudhanand.
Sudhanand,
Does the table below summarize what you are seeing?
CCS
What error do you see when you try to load using CCSv5.1? CCS should be doing a data verification test so it would give you data verification errors if it did not load properly. During data verification we read back some of the locations that were written and verify them against what we were writing. If it is not loading properly you should absolutely be getting errors.
Any chance that you have it set to load symbols only?
Can you provide the executable you are loading so that we can confirm this behavior. If you don't want to attach it to a forum post you can send it via email if you want.
John
If my reply answers your question please mark the thread as answered
Hi John,
Yes, the table summarizes what I am seeing.
The odd part is that CCS does not report any errors. I verified that I am loading the program not symbols. I also had a colleague test it on him PC and saw the same result.
I am attaching the executable (renamed to txt). It is a simple memory read-write test.
4118.ARMTest.txt
Thank you,
Forgot to mention, the code is built for a Cortex-A8
Which device?
I was able to reproduce this on DM8168. When I load in CCSv5.1 I only get symbols, when I load in CCSv5.0.3 the program loads and I end up at main(). I will file a defect for this.
I filed SDSCM00043927 to track this.
I tested it on TMS320TCI6614 simulator and Integra (DM816x) hardware.
Sudhanand
It looks like there is an issue with the program segment table generated by the linker.
Program Segment Table
id type load addr run addr file size mem size flags align
-- ---- --------- -------- --------- -------- ----- -----
0 PT_UNKNOWN (0x70000001) 0x8000b0dc 0x8000b0dc 0x8 0x8 r-- 4
1 PT_LOAD 0x80000000 0x80000000 0xb9c8 0xba2c rwx 32768
2 PT_LOAD 0x90000000 0x90000000 0x0 0x10000000 rw- 32768
The PT_LOAD segment (index 1) for the executable code has a p_offset ( file offset to the data ) set as 0x00000000; which is obviously incorrect because this is right at the beginning of the file where the ELF header is located.
Note: The there is slight difference in the behavior between older/newer versions of CCS. We used to load data from the offset regardless of weather it was incorrect or not; now we do not. Thus, in older versions you might actually see data getting loaded. However, it the loaded data is incorrect.
Hi Mandeep,
I have attached the linker command file I used (renamed from gcc_a8.cmd) and the generated map file (armTest_map.txt). Can you tell me what needs to be changed to correct the error.
.
Thank you.
The attachments did not come through. I am not sure how familiar our team is with gcc link files.
John,
I am going to try sending the file once more.
Can you tell me what the possible reasons that could cause the p_offset to be incorrect. I am new to GCC world and could not find anything on this in any of the Codesourcery or GCC documents.
6175.armTest_map.txt
6253.gcc_a8.txt
I took a look at the file but unfortunately I don't know what is wrong with it. You could try Code Sourcery however I believe they now charge for support, might want to see if anyone on your team has a support contract. Or you could try posting in one of the public gcc forums that are available.