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.

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

Part Number: RM42L432
Other Parts Discussed in Thread: HALCOGEN, ARM-CGT,

Hello,

We are new to TI's ARM MCUs (formerly we've worked mostly with Atmel's). We are evaluating the RM42L432 for a project. We'd like to use TI's Clang toolchain rather than the "legacy" ARM-CGT toolchain. However, HALCoGen does not generate Clang-compatible code. (We have read about this on E2E and verified it for ourselves.)

What does TI recommend we do for peripheral drivers when using Clang?

Does TI provide peripheral driver source code that is compatible with Clang?

Does TI provide some tool other than HALCoGen that generates peripheral driver source that is compatible with Clang?

Are there plans to replace HALCoGen with something that is Clang-compatible or to update HALCoGen?

Thanks in advance!
-sam

  • 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

  • Hi Sam,

    I recommend to keep using TI ARMCL compiler instead of switching to TI ARM Clang compiler.