RM42L432: Looking for RM42L432 peripheral drivers that are compatible with ARM-CGT-CLANG

Hi Sam,

I am sorry that our HAL code doesn't fully support TI Clang compiler. Please use the guide in the following link to migrate the code:

https://software-dl.ti.com/codegen/docs/tiarmclang/compiler_tools_user_guide/migration_guide/behavioral_differences/index.html

Thanks for the quick reply, QJ. We started to modify the code following the migration guide and ran into some problems. Perhaps you can help?

1. In source/sys_startup.c, the function _c_int00 is marked with __attribute__ ((naked)), which Clang rejects because the function body is not pure assembly. The migration guide does not address this situation. We removed the attribute, but we don't know what the implications if this might be. What is the correct change to make?
2. Also in _c_int00, there is a block of code that initializes the data segment:

       {
           extern uint32 _sidata, _sdata, _edata;
           uint32 *src, *dst;
           src = &_sidata;
           dst = &_sdata;
              while (dst < &_edata)
              {
               *dst++ = *src++;
           }
       }

   The symbols _sidata, _sdata, and _edata are defined in the linker script generated by HCG (sys_link.ld). This script is not compatible with LLVM's linker, and the LLVM-compatible linker script generated by CCS (RM42L432FlashLnk.cmd) does not define them. What can we add to the linker script to define these symbols, or is there another way to refer the same memory addresses?

Even if you are able to help us resolve these issues, we have some concerns about the suggested approach:

1. It requires modifying HCG-generated code outside of the "USER CODE" sections. As this project progresses, we may need to tweak the HCG configuration and re-generate the code. Whenever we do this, we will have to re-apply the Clang-compatibility changes.
2. If we enable additional peripherals in HCG, this will generate new code that we will then have to migrate. Perhaps we will run into novel migration challenges that take a while to resolve. This could make predicting project timelines more difficult.

We'd like to know whether TI recommends using Clang for new Hercules projects, and if so, whether TI can offer us Clang-compatible peripheral driver source code. "Just migrate the broken code that HCG generates" is not a very pleasing solution, in my opinion.

Thanks for your insight,
-sam