Other Parts Discussed in Thread: OMAP-L138
Tool/software:
I have started working with a large legacy code base, and am new to the TI DSPs. I was surprised to learn that the startup code does not initialise global and static variables except when explicitly set to non-zero values. However, some of the code already in the code base has been written without consideration of this and so don't explicitly initialise variables in the code, which means we are vulnerable to bugs arising when variables take on unexpected values (and have had a number of such bugs already manifesting).
I am using:
- TMS320C6748 chip
- compiler C6000 v7.4.4
- ABI = COFFABI
- --rom_model (although we are running the code from RAM in most cases)
The boot structure is somewhat complex with a number of different binaries which can run depending on the scenario. One example scenario is:
- Primary bootloader (bespoke): "loc_boot"
- > passes control to secondary bootloader: "loc_sec_boot"
- > passes control to one of 3 applications: "loc_prd", "loc_usb1" or "loc_comm1"
Each binary is built as a separate application, and can re-use memory used by previous images.
Some of the images place some data and code sections (including the .bss and .far sections) in SHAREDRAM.
In the example scenario shown above, I am seeing that, when the control is passed to the "loc_prd1" app and enters the application main() function, many of the variables in the .bss section have not been initialised to zero though I would expect them to be, and instead inherit whatever they have been set to by the "loc_sec_boot" binary. This is causing unexpected behaviour in loc_prd1.
My question is, in this scenario, what is the recommended practice for initialising global and static local variables which need to be set to zero?
