Compiler/TMS320VC5502: Use of "ALIGN 16" for text section in .cmd file

Align 16 will force the linker to align that one section to a 16-byte aligned address. That is, (address % 16 == 0). The .text section for C55x does not necessarily need to be aligned in any way as far as the CPU is concerned. I have no idea why the firmware would have such a requirement.

Can you tell us more about how you know the firmware is stuck? Is it in an infinite loop? Does the CPU crash or halt? What is happening when this failure occurs?

It is observed that control is not returned to calling function after calling 1 function. So PC lost its link and program gets stuck.
Both calling and called functions are in different text section. When i add ALIGN 16 to both of them, its working.
Both of them are library functions written in C.

I read somewhere that if RET instruction is on odd address, due to parallel pipeline execution, it can create an issue during execution.

Saurabh Shah1 said:

I read somewhere that if RET instruction is on odd address, due to parallel pipeline execution, it can create an issue during execution.

I am unfamiliar with such a problem. If an unaligned RET instruction could cause incorrect execution, that would be a silicon exception and the compiler would need to deal with it.  Where did you read this?

Saurabh Shah1 said:

When i add ALIGN 16 to both of them, its working.

C55x text sections aren't supposed to need any alignment at all.  That is, the CPU is supposed to be able to read and execute instructions from the .text section correctly, regardless of the alignment.  Yes, certain constructs like RPTBLOCAL and RPTB may be affected by the alignment of the instruction, but you shouldn't need any alignment on the .text section to get correct execution.

On the other hand, alignment can affect the performance of the fetch pipeline.  Some developers choose to align the .text section to avoid timing fluctuations due to small changes in the assembly code.  Even so, the program should still execute properly, as far as the CPU is concerned.

Check that your .stack and .sysstack are both large enough, and that you have not overflowed one or the other.  Which stack mode are you executing in?  Does the stack mode change during the execution of the program?

.stack & .sysstack are large enough to accommodate function depth.

Please refer "A.10 TMS320C6000" in spraa46a.pdf. As per TI FAE, same issue can happen in C55x series. But i have not found any related doc.

Most of section A.10 does not apply to C55x at all. Please refer to section A.11, which is specific to C55x.

It is true that if you have input sections which are for some reason aligned, it is possible that there will be holes between them, as described in A.10, but code sections do not (strictly speaking) need any alignment as far as the CPU is concerned, so you probably don't have aligned .text sections, so you wouldn't have many alignment gaps. Even if you do have aligned .text sections, the alignment gaps won't be very big, so you can ignore section A.10 as far as C55x is concerned. It's much more of a concern on C6000 devices.

Are any of the functions hand-coded assembly? Check functions in the call stack, and also any hand-coded assembly functions that may have been called recently.

Which stack mode are you executing in? Does the stack mode change during the execution of the program?

No functions are hand-coded assembly by us in our program. But we are using third party libs, so cant comment for it.

Stack mode - 16-bit fast return (USE_RETA)

Archaeologist said:

Were you able to recall where you found this information?

No.

Archaeologist said:

What version of the compiler are you using?  (It is different than the CCS version).

Code generation tool -  V3.2.2

Archaeologist said:

Are you passing the appropriate CPU version flags to the compiler so that it can check all known silicon exceptions?

Yes.

Custom Target (-v) : 5502

That's a pretty old version, so it probably doesn't have all of the silicon exception detection checking.

You should at least upgrade to patch version 3.2.3. You should consider upgrading to 4.4.1.

A problem like this at the call or return site is often caused by stack corruption (typically caused by buffer overrun or a stray pointer access), or the stack not being restored properly (typically caused by a mistake in hand-coded assembly). Due to the fact that C55x uses the RETA register, you won't see the symptom immediately after the corruption; you often won't see the problem until you try to return to the grandparent of the function where the problem occurs. However, I haven't seen anything in this thread that leads me to believe that's what's going on.

Other than that, I'm out of ideas. I can't find any relevant silicon exception; however, there could still be one I don't know about. Aligning .text (or just RET) shouldn't be necessary to the CPU, as far as I know. If there is some requirement from the firmware (which I am completely unfamiliar with), I don't know where to begin looking for a requirement.

I tried with compiler version 4.2.3. It is working fine.