TMS570LC4357: Use of TI Arm Clang Compiler

Wesley Lentz said:

Can someone provide a simple hello world example program that compiles, links, and executes for the TMS570LC4357 MCU using the TI Arm Clang Compiler or let me know if the Clang compiler is not yet supported for this board?

From ARM-CGT: From ARM-CGT to ARM-CGT-CLANG-X ..? The TI Arm Clang compiler isn't officially supported with HALCoGen.

https://github.com/Chester-Gillon/E2E_example_projects/tree/master/TMS570LC4357_TI_compilers_halcogen is an example of a project where I did get the TI Arm Clang compiler to work with HALCoGen. The Debug_TI_CLANG build configuration in the CCS project uses the TI Arm Clang compiler.

Wesley Lentz said:

However, the program does not execute correctly on the target. The program appears to never enter main and instead aborts during _c_int00

From memory the program did work when created, but I don't have the hardware at the moment to test it.

Which version of CCS are you using?

Possibly related is Program is not being properly loaded to the correct load address for big endian devices which was found in CCS 11.0 and fixed in CCS 11.1

Hi sir thank you for the quick reply. I am using CCS version 11.0, however I can confirm the binary is correctly loaded onto the target as the initial PC is pointing to the _c_int00 address.

However the fact that HALcoGen is not officially supported makes me think we don't want to go the route of TI Arm Clang until official support for the Hercules is provided. Is there an estimated timeline when official HALcoGen support for tiarmclang is anticipated?

Wesley Lentz said:

Is there an estimated timeline when official HALcoGen support for tiarmclang is anticipated?

I'm not a TI employee so can't comment on that.

Wesley Lentz said:

However, the program does not execute correctly on the target. The program appears to never enter main and instead aborts during _c_int00

I have gone back and investigated. The TMS570LC4357_TI_CLANG_hello example was originally developed using CCS 10.3 and TI Clang v.1.3.0-beta-1.

I have taken the same project, changed to the TI Clang v1.3.0.LTS compiler, and tested under different CCS versions:

With CCS 10.3 the example runs correctly.

With CCS 10.4, 11.0 or 11.1 the example doesn't run correctly. Gets an UNDEF exception on attempting to execute the first instruction.

The issue seems to be coming from an incorrect endianess in the executable.

The following the Disassembly view for the entry point when built with CCS 10.3 and works:

          _c_int00():
0003f89c:   EE110F50            mrc        p15, #0, r0, c1, c0, #2
0003f8a0:   E3A0360F            mov        r3, #0xf00000
0003f8a4:   E1800003            orr        r0, r0, r3
0003f8a8:   EE010F50            mcr        p15, #0, r0, c1, c0, #2
0003f8ac:   E3A00101            mov        r0, #0x40000000
0003f8b0:   EEE80A10            vmsr       fpexc, r0
0003f8b4:   E10F0000            mrs        r0, apsr
0003f8b8:   E3C0001F            bic        r0, r0, #0x1f
0003f8bc:   E3800010            orr        r0, r0, #0x10
0003f8c0:   E129F000            msr        cpsr_fc, r0
0003f8c4:   E59FD020            ldr        r13, [pc, #0x20]
0003f8c8:   EBFF65DF            bl         __mpu_init
0003f8cc:   EBFF4BFD            bl         _system_pre_init
0003f8d0:   E3500000            cmp        r0, #0
0003f8d4:   0A000000            beq        #0x3f8dc
0003f8d8:   EBFFFE9B            bl         __TI_auto_init_nobinit_nopinit
0003f8dc:   EB0004E3            bl         _args_main
0003f8e0:   E3A00001            mov        r0, #1
0003f8e4:   EBFFFFD7            bl         exit
0003f8e8:   EAFFFFFE            b          #0x3f8e8
0003f8ec:   08073500            stmdaeq    r7, {r8, r10, r12, r13}

And the following is the Disassembly view for the entry point when built with CCS 11.1 and gets an UNDEF exception on the first instruction:

          _c_int00():
0003f89c:   500F11EE            andpl      r1, pc, r14, ror #3
0003f8a0:   0F36A0E3            svceq      #0x36a0e3
0003f8a4:   030080E1            movweq     r8, #0xe1
0003f8a8:   500F01EE            andpl      r0, pc, r14, ror #3
0003f8ac:   0101A0E3            smlatteq   r1, r3, r0, r10
0003f8b0:   100AE8EE            andne      r14, r10, r14, ror #17
0003f8b4:   00000FE1            andeq      r0, r0, r1, ror #31
0003f8b8:   1F00C0E3            svcne      #0xc0e3

Note that the 32-bit instruction hex values are endian-swapped between the working and non-working program.

With the project built with CCS 10.3 which works correctly, the CCS generated makefiles are passing the --be32 option the linker. Whereas when the same project is built with CCS 10.4, 11.0 or 11 the --be32 option isn't passed to the linker.

There is something strange in how the CCS versions are interpreting the endianess of the device when using the same .project, .cproject and .ccsproject files.

In CCS 10.3 the Device endianess is reported as BE32:

Whereas with the same project in CCS 11.1 the Device endianess is reported as Big:

This looks to be a CCS issue, potentially with the device files. Will try and investigate.