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.
I have been using a way to create a common data struct in FLASH memory at a specific address for many years. The struct is initialized and contains exchange information used between separate applications. This has been working just fine in the C2000 world.
I am trying to transfer this system to the TMS570LC4357 (ARM) using TI compiler v5.1.9 at this moment. No matter what I do, the linker is putting the initialization values for the struct in the .cinit section and making an attempt to initialize the FLASH during startup. It is trying to write the initialization values to the correct address, but obviously the FLASH is not ready to accept those.
I have tried pretty much everything including an assembler version similar to "HL_sys_intvecs.asm", but nothing is working! The initialization values are pointers to strings, pointers to functions and regular integers. Any ideas out there???????
Thank you!!!
Is the initialized structure const qualified?Marek Christer said:No matter what I do, the linker is putting the initialization values for the struct in the .cinit section and making an attempt to initialize the FLASH during startup.
It the initialized structure isn't const qualified the linker will try and initialize the structure at run time.
How to correctly declare initialized data into FLASH using C/C++ has an example CCS project, for a TM4C ARM device, which places constant structures in flash in a custom section.
The C2000 compiler only supports one ABI (application binary interface) called COFF ABI. The ARM compiler supports the older COFF ABI and a newer ABI named EABI. The ARM compiler uses EABI by default. Thus, you are changing from COFF ABI to EABI. I don't specifically know that is the cause of your problems. But I suspect it is. Please show one small example of the C source for a structure which is not getting initialized properly. I think I'll be able to explain what is occurring.
Thanks and regards,
-George
#include "ProjectSpecificDefinitions.h"
#include "commonUDS_midpt.h"
extern void _c_int00 (void);
#pragma RETAIN(BootloaderInfo)
// Flash structure definition for the application interface//
#ifdef __cplusplus
#pragma DATA_SECTION("MidptFile")
#else
#pragma DATA_SECTION(BootloaderInfo, "MidptFile");
#endif // __cplusplus //
BOOTLOADER_INFO_CV_QUAL BOOTLOADER_INFO BootloaderInfo =
{
FLASH_ERASED_STATE_16, // bootInfoIdentifier //
FLASH_ERASED_STATE_16, // bootInfoVersion //
(char *)FLASH_ERASED_STATE_PTR, // BootBuildVersionPtr //
(char *)FLASH_ERASED_STATE_PTR, // BootBuildDatePtr //
(char *)FLASH_ERASED_STATE_PTR, // BootBuildTimePtr //
(void (*)(void))FLASH_ERASED_STATE_PTR, // BootEntryPtr //
BOOT_APP_BUILD_VERSION_STRING, // AppBuildVersionPtr //
__DATE__, // AppBuildDatePtr //
__TIME__, // AppBuildTimePtr //
BOOT_APP_PART_NUMBER_STRING, // AppPartNumberPtr //
_c_int00, // AppEntryPtr //
(char *)FLASH_ERASED_STATE_PTR, // AppStartAddressPtr //
(char *)FLASH_ERASED_STATE_PTR, // AppEndAddressPtr //
FLASH_ERASED_STATE_16, // onChipChecksum //
FLASH_ERASED_STATE_16, // downloadCount //
FLASH_ERASED_STATE_16, // reserved_1 //
FLASH_ERASED_STATE_16, // reserved_2 //
FLASH_ERASED_STATE_16, // reserved_3 //
FLASH_ERASED_STATE_16, // reserved_4 //
FLASH_ERASED_STATE_16, // reserved_5 //
FLASH_ERASED_STATE_16 // checksum //
};
// end of file commonUDS_midptapp.c //
George,
What you see above are the complete contents of the C-file creating the struct. MidptFile is located in a memory section defined to be at 0x0000C000 using a linker command file. The memory is specified as (RIX) and I did try all kinds of alternate combinations. No matter what I do, in the map file this memory comes out as 'rw'.
BOOTLOADER_INFO is the struct definition, while BOOTLOADER_INFO_CV_QUAL is a define that is not specified in the bootloader code, but #defined as volatile const in the applications. I did try to remove the volatile part with no difference. I kind of expected that, as volatile should only have impact on the optimizer. All optimizations are disabled anyway...
I sure hope that you can figure this one out!!! It has been holding me up for almost a week now!
Thank you!
Marek
I don't see anything here that explains your problem. That said, I'm having to guess about a few details. I might be guessing wrong. Please send the source file which contains this problem structure, preprocessed like this . I also need to see the exact compiler options you use when building it.
Thanks and regards,
-George
George, here is an update. While trying to provide you with a sample, I took the offending C-file and needed .h files (only two)and created a brand new project with a single main() that reads some of the struct data. I have no HalcoGen initialization files and no startup code whatsoever. The project compiled and linked just fine and the struct was programmed properly in the FLASH at address 0x0000c000.
Main difference #1 - the project was created from scratch and NOT imported from CCS3.3. I will compare all the project settings for the two projects tomorrow.
Difference #2 - no initialization code from HalcoGen present.
Difference #3 - the remainder of our code is left out with unknown pragmas eliminated.
The first thing tomorrow will be to compare the project build settings. After that it will get tough, as I am not sure how to build the project (and link) with only partial files present.
I just hope that there is some kind of a simple issue with a build setting!!!
Marek
PS Is there some simple way to print out the complete summary of the project settings for comparison between two projects?
This has been one of the most frustrating experiences in my professional life, and I have been around for a long time!
I have two projects now. One that is building just fine and one that is not. I did compare the project settings and those are identical.
A few comments: The CCS is tuning off the ARM Hex utility by it's own decision, and always after a software upgrade - not good! The set of flags in the compiler and linker calls is changing for the same project between different times when CCS is invoked. When opening the properties window on the "Build" selection and the last time the window was open the "Dependencies" tab was selected, no other tabs are visible. Yes, there are two tiny arrows on the right side of the window indicating that this is the view of window number two. Sorry, but that is a horrible presentation!
I looked at the pragmas in the project. Our original files had a lot of pragmas to load code sections into RAM, as the older CPU's required the FLASH burning access to be performed from RAM. All of these pragmas are commented out. The only pragmas present in the project are the ones created by HalcoGen for the interrupts. I added one RETAIN pragma for the struct in question, but it is not really necessary and the pragma exists in both projects.
The "preprocessed" file versions do not make any sense at this moment. What I did in the last hour was to start adding nothing else but our .h files to the project that was linking properly. Those definitions should be insignificant; however, the linking finally failed in the same way as the original project. After lunch I will start commenting out the .h files and later the contents until I find the offending statement(s).
Marek
Marek,
One possibility is that a section that is marked read/write is being included in the output section that is being placed in flash. In this case, the linker will make the entire output section read/write which will cause initialization from .cinit. Can you post the linker command file you are using and the map file from the linker. This might help to shed some light on the problem.
Marek Christer said:
The option --gen_acp_raw can help you see what happens during preprocessing. Read about it in the ARM compiler manual.
Thanks and regards,
-George