MC9s12XET256 Warnings

[Radharapu]

L1128: Cutting value Range beg data member from 0xFC1000 to 0x1000

c12056: SP Debug info incorrect because of optimization or inline assembler 

c5660: Removed dead assignment error occurring for global and local variables even though                 we are using this variables 

[lama]

Hi,

It is not possible to say anything without code which reports messages.

However, have you read the description of the messages in help
go to index in help

and....

Best regards,

Ladislav

[Radharapu]

yes ,we have gone through the description of the messages but why that error occurring even though it is used

[lama]

Hi,

As I mentioned earlier, without analyzing the actual code, it's difficult to give a definitive answer.

The compiler applies various optimizations that can affect how variables are treated. For example:

Global variables that are only read and never written may be treated as constants.

Dead code elimination can remove assignments or entire blocks if the compiler determines they are never executed.

Debug info issues (like c12056) often arise due to aggressive optimization or use of inline assembly, which can interfere with symbol tracking.

If a variable should not be optimized away or altered, consider:

Declaring it as volatile to prevent the compiler from optimizing access.

Making it static if it's only used within one translation unit.

Ensuring it's used in a way that the compiler recognizes as meaningful.

From my experience, even a small logical condition elsewhere in the code can cause a block to be unreachable, triggering a dead code warning. In one case, I had a condition set in another module that made a section of code unreachable, and the compiler rightly removed it.

 My recommendation:

Go through the code step by step and:

Check how each variable is used.

Review compiler optimization settings.

Compare expected vs. actual behavior.

Use debugging tools to trace variable usage and code flow.

This is the only reliable way to understand and resolve such issues.

Best regards,

Ladislav