RM48L952: Is it possible to compile certain TI Source codes on ARM FuSa Compiler and then debug with TI Tool chain ?

Also, to accomplish my task here (listed above) which compiler do you think I should be using, from the  following two (2) options?

• TI ARM 20.2.7 LTS
• TI Arm Clang C/C++ Compiler Tools

TI describes the differences here:

https://software-dl.ti.com/codegen/docs/tiarmclang/rel3_2_2_LTS/

The TI Arm Clang C/C++ Compiler Tools replace the existing TI Arm C/C++ Compiler Tools. All new feature development will be done in the TI Arm Clang C/C++ Compiler Tools. The last feature release of the armcl compiler toolchain is v20.2.x.LTS, which will continue to be actively supported as long as necessary. However, only bug fixes will be provided in maintenance releases of v20.2.x.LTS of the armcl.

Both toolchains can be used to compile and link C/C++ and assembly source files to build static executable applications. These applications can then be loaded and run on Arm Cortex-M and Cortex-R series devices. Depending on the device family you are using a specific compiler toolchain will be recommended. Please refer to the SDK for the device family for information on which toolchain to use.

Hi Kip,

I started working on your issue and will provide my updates ASAP.

--
Thanks & regards,
Jagadish.

Thanks !  I can use your help.  Here is the latest set of Arm FuSa linker errors.  It looks like all these symbols are part of the run-time C/C+ environment setup.  Most of them seem to be before the ENTRY POINT of main(), but there is also one in the file exit.c.  For some reason, they aren't getting defined (or included) before the ARM Linker step.

Error: L6218E: Undefined symbol __cpp_initialize__aeabi_ (referred from anon$$obj.o).
Error: L6218E: Undefined symbol __hardfp_floor (referred from sci.o).
Error: L6218E: Undefined symbol __aeabi_unwind_cpp_pr1 (referred from sys_main.o).
Error: L6218E: Undefined symbol __main (referred from anon$$obj.o).
Error: L6218E: Undefined symbol WDTCTL_SYM (referred from autoinit.c.obj).
Error: L6218E: Undefined symbol __binit__ (referred from autoinit.c.obj).
Error: L6218E: Undefined symbol __TI_pprof_out_hndl (referred from exit.c.obj).
Error: L6218E: Undefined symbol __SYSMEM_SIZE (referred from memory.c.obj).

Given that you did this ...

Kip Leitner said:

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. 

... you should consider using the TI safety compiler qualification kit.  I suggest you download it and start using it.  I suspect you'll understand, in a short amount of time, whether it is appropriate for your system.

I take this ...

Kip Leitner said:

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

... to mean you are starting all over with the Arm FuSa compiler.  Here are some points to consider.

My knowledge of HALCoGen is limited.  I presume it is documented and tested to work with only a few compilers.  If you use a different compiler, then TI may not be able to support you.  Someone from the team that supports HALCoGen should comment on this point.

If something else goes wrong, you should seek support from the team that supports the Arm FuSa compiler, and not TI.

I doubt anyone has tested the combination of the Arm FuSa compiler and CCS.  I suspect it mostly works, but a few minor things will not go smoothly. 

Thanks and regards,

-George

Thanks George for commenting!  Having your input helps us a lot.

To scope the business opportunity properly, I want to mention that I am authorized by my company to reveal that in 2025 we plan to buy 35,000 Functional Safety microcontrollers to comply with 60730-1, and that the Hercules RM48 class is currently the leading contender.  We are also considering a chip from Microchip.  This is a big opportunity for everyone.

> Someone from the team that supports HALCoGen should comment on this point.

I'm waiting from TI for a specific answer to this.  Using the HALCoGen is a huge advantage to us because it dramatically shortens the time to market.

Also, a core question I have for the TI compiler team is the confidence level in the TI compiler ARM 20.2.7 LTS in generating AEABI compatible objects.  The TI compiler manual says objects are EABI compatible if the following flags are set:

--define=_AEABI_PORTABILITY_LEVEL=1
--abi=eabi
--asm_define=__TI_EABI_ASSEMBLER

However, there are different versions of ARM EABI in existence, as the EABI specification evolved over years.  There are places in the TI source code which mention this fact.  So it would help me if someone at the TI team can tell me whether the case of LTS compliance with EABI

• Works almost perfectly (none or few changes to source code in most cases)
• Works OK                     (More changes required to source code)
• Doesn't work very well (Source code may be incompatible in non-trivial ways and may require a lot of cleanup to compile cleanly)

Also, another question I have, from my looking at the TI Source code, which appears fairly simply to answer would be that the following source code construct used to create the runtime C/C++ lib is use in the same way wherever the macro is used.  This suggests that TI's EABI solution is static (finished) and probably works completely, but I'd like to know this for sure.  Can someone comment?

#if defined(_AEABI_PORTABILITY_LEVEL) && _AEABI_PORTABILITY_LEVEL != 0

George, I am also doing as you suggest and reviewing the Compiler Compliance package from TI. 

At the end of the day, the issue for me is total Level Of Effort (LOE )for proving LTS compiler compliance with 60730-1 as compared with getting a build with TI source HAL working in the ARM compiler environment.  I'm only a few days work into porting code to work in ARM environment, and I only have 7 link time errors left.   If I can fix these then the LOE is ***way shorter*** than having to prove TI LTS compliance.

One thing that can help me is if TI can comment on whether or not the TI compiler actually needs certification for 60730-1.

Micropchip makes an (unverified) claim that a "Functional Safety" compiler is not needed for Class B software.  Does TI agree with this with regard to its 20.2.7 LTS compiler ?

Thanks for any information you can give.

Kip

I am waiting for someone at TI to answer the following:

1. Can the HAL-generated code be built with other compilers?
   
   1. George Mock at TI asked someone on the TI HALCoGen team to answer, but no one did.
   2. We need an answer to this, please.
2. Does TI believe that the compiler 20.2.7.LTS can be certified for 60730-1 WITHOUT all of the in-depth certifications required for certs built on 60508 ? (such as 26262)?  That is, does TI basically stand by this version of the compiler as something that basically works for C/C++ without the exception handling system, RTTI, and other exotic features, I'd like to know.  I'm just asking for general opinion from TI from someone internal there. 

Thanks for checking.  As previously discussed, this is an 35,000 Hercules RM48x / year business opportunity for TI.

Also, the UL-60730-1 requirement points to 61508-7 spec shown below.  The critical thing is this:

Is there some way that it can be shown that the 20.2.x LTS series of the TI compiler for C/C++ has been in evolution for a very long time and is generally a very mature, generally bug free "translator," per the below

(excerpt from UL-60730-1)

H.11.12.3.4.1 Tools, programming languages
Equipment used for software design, verification and maintenance, such as design tools, programming languages, translators and test tools, shall be qualified appropriately, and shall be shown to be suitable for purpose in manifold applications. They are assumed to be suitable if they comply with ²increased confidence from use² according to C.4.4 of IEC 61508-7:2010

(excerpt from IEC-61508-7)

C.4.4 Tools and translators: increased confidence from use
NOTE This technique/measure is referenced in Table A.3 of IEC 61508-3.

Aim: To avoid any difficulties due to translator failures which can arise during development, verification and maintenance of a software package.

Description: A translator is used, where there has been no evidence of improper performance over many prior projects. Translators without operating experience or with any serious known faults should be avoided unless there is some other assurance of correct performance (for example, see C.4.4.1).

If the translator has shown small deficiencies, the related language constructs are noted down and carefully avoided during a safety related project.

Another version to this way of working is to restrict the usage of the language to only its commonly used features.

This recommendation is based on the experience from many projects. It has been shown that immature translators are a serious handicap to any software development. They make a safety-related software development generally infeasible.

It is also known, presently, that no method exists to prove the correctness for all tool or translator parts.

Hi Kip,

Apologies for the delay, i am reassigning this thread to QJ as it is looking very priority issue. QJ working on these Hercules devices from so long and he has most experience than me.

Hopefully he will provide you suggestions soon.

--
Thanks & regards,
Jagadish.