eZdsp5502 FAQ

Frequently asked questions.

Release Notes

The 4.3.8 linker that ships with Code Composer 4.x has a bug that introduces holes in between functions. The linker tries to align functions on 32-bit boundaries. When a function ends and a pad must be inserted to get to the next 32-bit boundary, uninitialized bytes can be found betweet the final instruction of the function and the start of the next function. In the example below, 0x48 0x04 is a RET instruction and the xx xx bytes are uninitialized random data.

10b8: 48 04 xx xx RET

If the values of xx xx happen to correspond to a valid opcode they can represent an unintended instruction that executes in parallel with the RET instruction. In the following example, the parallel executed instruction does not have a critical side effect.

10b8: 48 04 03 24 RET || RETCC T0 < #0

However, the following will fail when executed because the POP instruction alters the stack pointer at the same time the RET instruction is trying to use it to return from the function.

10b8: 48 04 3b 8b RET || POP AR0,AR3

The examples that ship with the eZdsp5502 have modified linker command files (lnkx.cmd) to defeat this behavior. The .text section is aligned to 32-bit boundaries and filled with the value 0x20 (which corresponds to a NOP instruction). In addition, the directive { * (.text) } tells the linker to keep all of the functions within a source file together.

.text > DARAM align(32) fill = 20h { * (.text) }

This ordering helps to pack the functions in an order that does not introduce uninitialized holes. In particular, the linker seems to have more problems when a function from one source file is followed by a function from a different source file. The CCS 3.x linkers tended to keep functions within a source file together while the CCS 4.x linkers tend to reorder functions based on internal metrics, which makes the issue described here much more prevalent.

©Copyright 2002-2016 Spectrum Digital, Inc. All Rights Reserved.