compatibility ThreadX <-> TI compiler for assembly files

Alexandre Bruliau 30

Hello,

I am trying to port ThreadX on a TMS570 (cortex R4F) using TI compiler (v20.2.0.LTS).

I just took the .*s files from the ports/cortex_r4/ac5 in my application but the assembly directives don't seem to match with the one supported by the TI compiler since I got a bunch of "Illegal mnemonic specified" (see section 5 https://www.ti.com/lit/ug/spnu118z/spnu118z.pdf?ts=1694684652430&ref_url=https%253A%252F%252Fsoftware-dl.ti.com%252Fcodegen%252Fdocs%252Ftiarmclang%252Fcompiler_tools_user_guide%252Fmigration_guide%252Fmigrating_assembly_source%252Fconverting_ti_syntax_asm_to_gnu_syntax_asm%252Fdirectives.html

Any ideas for solving this issue ?

Best regards,

Alex

LeelaRajeshSayana-MSFT 13,871 Reputation points

2023-09-15T13:18:36.9+00:00

Hi @Alexandre Bruliau Thank you for posting the question here. Our community SMEs on this this topic will review this question and get back to you with more details as soon as possible. Please stay tuned to this for updates.
Kip Leitner 0 Reputation points

2023-10-10T22:10:46.15+00:00
Hi, I have almost the identical problem. In larger context, I am also using TI Hercules class processor (TI "Hercules" RM48L952), which also has ARM Cortex_R4F so-called "lockstep" processor. The problem is that there are two libraries built with two different tool chain sets.

Thread X can be built with

ARM5

ARM6

GNU

GHS

IAR

TI Startup Code (thousands of lines) can only be built with TI Compiler

20.2.7.LTS (or earlier) compiler.

TI ARM Clang (under development, not yet ready.)

Now, it's not feasible to port TI startup code or 60730 compliant TI source code for POST and periodic self-test (PST) to one of the threadx build environments. That would be huge amount of work. I estimate 3 months for total expert in Hercules and ARM architecture. It would take me at least 6 months to do this minimum.

What Bruliau did in this ticket was try to port Thread X code to work inside TI's Code Composer Studio (CCS). This might work, but there are THREE DRAWBACKS:

It's a lot of work. (Well maybe not so much, but amount is unknown).

It's DANGEROUS, because the porting rules for Thread X have to be followed EXACTLY, and COMPLETELY, or there might be unexpected behavior of the threadx <--> TI code inter-binary calling.

Because Bruliau is using Hercules class processor, we can assume the end product is for "functional safety" so any resulting ThreadX port designed to be built under TI 20.2.x.LTS compiler would have to be RECERTIFIED by MICROSOFT to achieve any of the current certifications. But this would we highly unorthodox and almost certainly DENIED by Microsoft because a developer cannot get their port of threadx certified for UL-60730 or IEC-61508, since MICROSOFT OWNS THE PRODUCT.

I am experimenting with another solution: building ThreadX under all 5 of the different ports supported by Microsoft, using the specified tool chains, and then linking the RESULTING library into a TI build using TI 20.2.7.LTS compiler. I have this mostly working. To get this to work

BOTH compilers, assembler, linkers MUST use the same flags

To confirm that both results are compatible, the SW developer needs to use the following post build tools to dump the ABI compatibility flags to confirm that all code (and libs) generated by each of the 2 builds confirms to the ARM ABI interface specifications. This is quite a bit of work, but this is how one can prove that the Thread X lib (tx.a) is can be successfully linked and run with TI code built on 20.2.7.LTS.

To dump the ABI compatibility flags, used the following tools and then sort through the resultant data dump and scan for the ABI tags.

armofd (TI side)

readelf (threadx side

Now,

HERE IS MY QUESTION FOR MICROSOFT -----

Which tool chain, of the 5 that threadx can be built with, does Microsoft recommend for producing an output binary that is most likely to be easily configured (at build time with threadx build tools) so that it will be compatible with code built with TI tool chain.

Without going into all the details here, I can see that not all tool chains on the threadx side are capable of tweaking all the needed ARM ABI settings. I have some giant spreadsheets showing how to configure all this, but I was wondering, does Microsoft, who OWNS THE PRODUCT, have an opinion about which tool chain one should pick to try to get the maximum amount of configurability?

I hope someone at Microsoft can answer this.
Kip Leitner 0 Reputation points

2023-10-17T18:27:39.3466667+00:00

Anyone from Microsoft available to answer my question?

1 answer

Xiuwen Cai 366 Reputation points Microsoft Employee

2023-09-18T09:41:13.66+00:00

Hi @Alexandre Bruliau there is no port for TI compiler. But there is port for GNU compiler. If possible, you may use GNU compiler in the CCS for compiling the ThreadX ports. Or you may modify those assembly files to meet the format that supported by TI compiler.
Please sign in to rate this answer.

1 person found this answer helpful.
Alexandre Bruliau 30 Reputation points

2023-09-20T16:39:50.8066667+00:00

I have encountered run time issues after updating those GNU assembly files to make it compatible with TI compiler.

Here are the inputs :

compiler is in arm mode

last release of threadX 6.1 with default threadx flags

my system stack length is 0x800 (user stack length : 0x300 and the remain is shared equally between the others stacks FIQ, IRQ, ...

the _tx_initialize_unused_memory to the first available address after data section (data,bss)

Here is a sample of my application layer to test threadx with only one periodic thread executed every 5 ticks.

static U32 my_thread_counter; static TX_THREAD my_thread; /* **** Static Function Definitions **** */ static void my_thread_entry(ULONG thread_input); /* **** Function Definitions **** */ void OSAL_init(void) { TIMER_init(); tx_kernel_enter(); } void tx_application_define(void *first_unused_memory) { /* Create my_thread! */ UINT status = tx_thread_create(&my_thread, "My Thread", my_thread_entry, 0x1234, first_unused_memory, 1024, 3, 3, TX_NO_TIME_SLICE, TX_AUTO_START); } void my_thread_entry(ULONG thread_input) { /* Enter into a forever loop. */ while(1) { /* Increment thread counter. */ my_thread_counter++; /* Sleep for 1 tick. */ tx_thread_sleep(5); } }

The problem I am facing is after executing tx_thread_sleep, the mcu reset because the processor executes instructions it shouldn't. After going deeper in the code, the reset occurs after return instruction in _tx_thread_system_return() in _tx_thread_system_suspend at line 380 after 5 ticks. It should normally returned to the caller _tx_thread_sleep function but instead it branches to another address coming for the stack pointer at a certain offset witch correspond to the base address of my_thread variable. This unexpected behavior makes the mcu reset.

After executing _tx_thread_system_return(), this is a snapchot of the state :

the stack pointer is located at address 0x0801FDD4 and my_thread contains the following field

The two next instructions in asm offset the sp by 11 words with makes it point to 0x0801FE00 (in red) and load the program counter with the value inside with is 0x801A3FC that correspond to the address of myThread. I assumed the program counter should be loaded with the value of the caller.

Any ideas to manage issue ?

How can I debug easily ? (I already definedTX_ENABLE_STACK_CHECKING and I never entered _tx_thread_stack_error_handler)

Kind regards,

Alex

Kip Leitner 0 Reputation points

2023-09-22T18:40:51.1433333+00:00

I have same problem, except my processor is TI Hercules RM48L952. I tried building under all 5 ports available under cortex_r4 in the ThreadX build tree -- no joy. Agree the problem is the ASM directives.

Question for Microsoft -- why are you recommending GNU compiler ?
Sign in to comment

Share via

compatibility ThreadX <-> TI compiler for assembly files

1 answer