Other Parts Discussed in Thread: HALCOGEN
Tool/software:
Details:
I am working on a Functional Safety firmware build and am generating all my code inside the TI CCS using HALCoGen and using TI ARM compiler 20.2.7 LTS. All the code and libraries are building and linking properly within CCS. I load the object into TI's RM48 Hardware Dev Kit and it runs perfectly. Getting this all working properly has taken me about 3 months.
Because I need to certify my code under 60730-1, I need a compiler with Functional Safety certification. The ARM FuSa compiler is certified for $6,000 annual license.
So, what I want to do now, using the ARM FuSa environment, is compile and link all my (currently working) TI code, then load the object into the CCS debugger. After proving working, I will then cut my final Functional Safety compliant code using the ARM fuSa tools.
Theoretically, this should be possible. In actuality, I am very close to succeeding, with only 4 link errors left. But before doing the last little bit, and testing, I was hoping to get positive confirmation on feasibility.
There are a bunch of compiler / assembler / linker configurations that need to be setup identically in both tools chains to make this work. Libraries have to be built with AEABI settings the same. ASM code written for the TI Assembler uses the semicolon character ' ; ' for ASM code and there are 5 files generated by HALCoGen that need to be modified to be acceptable to the ARM Assembler.
I was thinking maybe some TI Guru, maybe George Mack, might be able to advise here on the possibility of success here. I only have 4 linker errors left under the ARM FuSa tool chain, but while fixing those, wondered if maybe George Mack might make a comment here. George commented on a similar problem here:
More Details specific to my build:
TI CCS Configs:
TI Compiler 20.2.7 LTS Settings
-mv7R4
--code_state=32
--float_support=VFPv3D16
-me
--include_path="${PROJECT_ROOT}"
--include_path="${CG_TOOL_ROOT}/include"
--include_path="${workspace_loc:/${ProjName}/Config_01_POC_HAL/include}"
--include_path="${workspace_loc:/${ProjName}/HET_IslandDER_01}"
--include_path="${workspace_loc:/${ProjName}/XDER_code/include_XDER}"
--include_path="C:/ti/Hercules/Cortex-R4 CMSIS DSP Library/1.0.0/Include"
--define=XDER_COMPILER_TI_20_2_7_LTS
--define=CCS
--define=_AEABI_PORTABILITY_LEVEL=1
--define=FPU_PRESENT
-g
--symdebug:dwarf_version=3
--c11
--cpp_default
--diag_warning=225
--diag_wrap=off
--display_error_number
--enum_type=packed
--abi=eabi
--asm_define=__TI_EABI_ASSEMBLER
TI Assembler 20.2.7 LTS Settings
-m"${ProjName}.map"
--heap_size=0x1000
--stack_size=0x1000
-i"${CG_TOOL_ROOT}/lib"
-i"${CG_TOOL_ROOT}/include"
--reread_libs
--diag_wrap=off
--display_error_number
--warn_sections
--xml_link_info="${ProjName}_linkInfo.xml"
--rom_model
Libraries: TI
C
C++
rtsv7R4_A_le_v3D16_eabi.lib
Libraries: Open Source
C:\ti\Hercules\Cortex-R4 CMSIS DSP Library\1.0.0\Lib\ti_math_Cortex_R4_lspf.lib
Here are the final 4 link errors from the ARM FuSa tool chain.
The first is lack of a definition which can be cleared by simply added the definition.
The other 3 related to the startup and C-Environment code generated by the HALCoGen.
Any idea what is triggering these errors? For instance symbol " __binit__" ends up with a value of "ffff ffff" in the TI map file. These errors look like they are being caused by unusual pre-processor Macro definitions not being defined do (possibly) to hidden rules inside the default compiler/linker builds for certain target architectures.
// +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
/* Four (4) Uncorrected errors from ARM DS FuSa Tool Chain Link, from the build log:
. . .
Cleaning up Comdat Group Sections
Renaming symbol __ARM_get_argv to __ARM_get_argv$full.
Renaming symbol __ARM_get_argv$stub to __ARM_get_argv.
Renaming symbol __I$use$heap_region to __heap_region$guard.
Renaming symbol __semihosting$guard to __I$use$semihosting.
Renaming symbol __rt_SIGABRT_inner to __rt_SIGABRT_inner$real.
. . .
Renaming symbol $$Temp to __rt_lib_init_clock_2.
Error: L6218E: Undefined symbol WDTCTL_SYM (referred from autoinit.c.obj). << Error #1 >>
. . .
Renaming symbol __rt_lib_init_cpp_2 to __rt_lib_init_cpp_1.
Error: L6218E: Undefined symbol __binit__ (referred from autoinit.c.obj). << Error #2 >>
. . .
Renaming symbol $$Temp to __rt_lib_init_exceptions_2.
Error: L6218E: Undefined symbol __TI_pprof_out_hndl (referred from exit.c.obj). << Error #3 >>
Error: L6218E: Undefined symbol __SYSMEM_SIZE (referred from memory.c.obj). << Error #4 >>
*/
Thanks for advice. Just to state again, need to know feasibility.
TI Compiler seems to suggest this is possible,
