Paul,

Could you please clarify? I thought that I had run into this specifically; I
was
loading a function pointer into a variable (local variable stored on the
stack)
and when I tried to call the function the processor reset. Looking into the
generated assembly I discovered that the error occured when attempting to
call the function pointer off the stack. I even went to the level of
stepping
through the assembly and saw that everything was in place so long as the
stack pointer was referenced correctly.

I can understand that the workaround is very easily implemented from the
compiler side (my in-line assembly was an attempt at doing this for the
compiler using a register instead) but does it not still represent the error
noted in the errata? Or perhaps you are referring to this not being a bug
at all but rather a change in the silicon that was not followed by a change
in the compiler?

(note that I realize the second bug quoted does not directly affect this
problem but I wanted to include it as it also seems unaddressed in CCE at
the moment)

Thanks :)

Paul Curtis wrote:
>
> Hi,
>
>> I'm working on a project for the 4618 and ran into a similar problem.
>> At this point (I was searching back in content in search of another
> problem I'm
>> having) you may have already discovered this, but the error you're having
> is the
>> result of a silicon error in the 2618. This is straight from the 2618
> errata
>> (http://focus.ti.com/lit/er/slaz033a/slaz033a.pdf):
>>
>> CPU7 CPU7 - Bug description
>> Module: CPU, CPU CALL, and PUSH instructions
>> CALL and PUSH instructions using @SP+, @SP, and X(SP) addressing modes
>> behave differently from original CPU. The original CPU predecremented the
> SP then used the
>> predecremented value to calculate the address. The new CPU uses the SP to
> calculate the
>> address, then decrements it.
>> Workaround: (Fixed in the compiler for C source. No silicon fix planned.)
>
> This is *not* a correct characterisation of the CPU7 bug. Really. TI
> need
> to update the buggy errata to *correctly* describe the bug. The fact CCE
> doesn't work around it just means CCE is a ball of old tar. Sorry,
> couldn't
> resist. ;-)
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
>

-- Start a New Thread

Beware that Assembler might also mess you up too!

--- In m..., CHoward wrote:
> After a bit of digging I see what you mean now, looks like while the
> end-symptom is the same the error is reversed. Running CCE v2.0.2.4
it does
> seem to compile for the errata and not the old behavior; thankfully the
> solution seems to be the same. Assembly or a different compiler
until CCE
> comes out with a fix.
>
> Appologies for not doing the digging earlier, I thought that I had a
grasp
> on what was going on before.
> Paul Curtis wrote:
> >
> > Hi,
> >
> >> Could you please clarify?
> >
> > Search the archives of this list.
> >
> > ? I thought that I had run into this
> >> specifically; I was
> >> loading a function pointer into a variable (local variable stored on
> >> the stack) and when I tried to call the function the processor reset.
> > Looking into
> >> the generated assembly I discovered that the error occured when
> >> attempting
> >> to call the function pointer off the stack. I even went to the
level of
> >> stepping through the assembly and saw that everything was in place so
> >> long
> > as
> >> the stack pointer was referenced correctly.
> >
> >>
> >> I can understand that the workaround is very easily implemented from
> >> the compiler side (my in-line assembly was an attempt at doing
this for
> > the
> >> compiler using a register instead) but does it not still
represent the
> >> error noted in the errata? Or perhaps you are referring to this
not being
> > a
> >> bug at all but rather a change in the silicon that was not
followed by a
> >> change in the compiler?
> >
> > No, I am saying that the ERRATA IS WRONG. It's almost correct but
IS NOT
> > ABSOLUTELY CORRECT. You probably are being hit by a bug in CCE which
> > doesn't correctly work around the buggy errata. It's not that CCE
didn't
> > try, it's that it didn't succeed. Sorry. Again, search the
archives for
> > a
> > correct characterization of this bug.
> >
> > --
> > Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> > CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
> >
> >
> >
> >
> >
> > --
>
> Start a New Thread

After a bit of digging I see what you mean now, looks like while the
end-symptom is the same the error is reversed. Running CCE v2.0.2.4 it does
seem to compile for the errata and not the old behavior; thankfully the
solution seems to be the same. Assembly or a different compiler until CCE
comes out with a fix.

Appologies for not doing the digging earlier, I thought that I had a grasp
on what was going on before.
Paul Curtis wrote:
>
> Hi,
>
>> Could you please clarify?
>
> Search the archives of this list.
>
> ? I thought that I had run into this
>> specifically; I was
>> loading a function pointer into a variable (local variable stored on
>> the stack) and when I tried to call the function the processor reset.
> Looking into
>> the generated assembly I discovered that the error occured when
>> attempting
>> to call the function pointer off the stack. I even went to the level of
>> stepping through the assembly and saw that everything was in place so
>> long
> as
>> the stack pointer was referenced correctly.
>
>>
>> I can understand that the workaround is very easily implemented from
>> the compiler side (my in-line assembly was an attempt at doing this for
> the
>> compiler using a register instead) but does it not still represent the
>> error noted in the errata? Or perhaps you are referring to this not being
> a
>> bug at all but rather a change in the silicon that was not followed by a
>> change in the compiler?
>
> No, I am saying that the ERRATA IS WRONG. It's almost correct but IS NOT
> ABSOLUTELY CORRECT. You probably are being hit by a bug in CCE which
> doesn't correctly work around the buggy errata. It's not that CCE didn't
> try, it's that it didn't succeed. Sorry. Again, search the archives for
> a
> correct characterization of this bug.
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors

-- Start a New Thread

Hi,

> Could you please clarify?

Search the archives of this list.

? I thought that I had run into this
> specifically; I was
> loading a function pointer into a variable (local variable stored on
> the stack) and when I tried to call the function the processor reset.
Looking into
> the generated assembly I discovered that the error occured when attempting
> to call the function pointer off the stack. I even went to the level of
> stepping through the assembly and saw that everything was in place so long
as
> the stack pointer was referenced correctly.

>
> I can understand that the workaround is very easily implemented from
> the compiler side (my in-line assembly was an attempt at doing this for
the
> compiler using a register instead) but does it not still represent the
> error noted in the errata? Or perhaps you are referring to this not being
a
> bug at all but rather a change in the silicon that was not followed by a
> change in the compiler?

No, I am saying that the ERRATA IS WRONG. It's almost correct but IS NOT
ABSOLUTELY CORRECT. You probably are being hit by a bug in CCE which
doesn't correctly work around the buggy errata. It's not that CCE didn't
try, it's that it didn't succeed. Sorry. Again, search the archives for a
correct characterization of this bug.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors Start a New Thread

If the compiler cannot handle CPU7 bug (or feature?) correctly, you
can fix the compiled code yourself.

Neither compiled code nor you own code should not put odd address in
SP. Thus CUP8 bug should not be a problem.

--- In m..., CHoward wrote:
> Colin,
>
> I'm working on a project for the 4618 and ran into a similar problem. At
> this point
> (I was searching back in content in search of another problem I'm
having)
> you
> may have already discovered this, but the error you're having is the
result
> of
> a silicon error in the 2618. This is straight from the 2618 errata
> (http://focus.ti.com/lit/er/slaz033a/slaz033a.pdf):
>
> CPU7 CPU7 - Bug description
> Module: CPU, CPU CALL, and PUSH instructions
> CALL and PUSH instructions using @SP+, @SP, and X(SP) addressing modes
> behave differently
> from original CPU. The original CPU predecremented the SP then used the
> predecremented value
> to calculate the address. The new CPU uses the SP to calculate the
address,
> then decrements it.
> Workaround: (Fixed in the compiler for C source. No silicon fix
planned.)
> None.
>
> CPU8 CPU8 - Bug description
> Module: CPU, using odd values in the SP register
> The SP can be written with odd values. In the original CPU, an odd
SP value
> could be combined
> with an odd offset (i.e., mov. #value, 5(SP)). In the new CPU, the
SP can be
> written with an odd
> value, but the first time the SP is used, the LSB is forced to 0.
> Workaround:
> Do not use odd values with the SP.
>
> In my project I was able to get around the problem using inline
assembly :
>
> ramFunc = (_ramFunc_ptr)(EXEC_RAM);
>
> // ramFunc( bufAddr, ramBuff, 512 );
> asm(" MOVX.A &bufAddr+0,r12");
> asm(" MOV.W #ramBuff+0,r13");
> asm(" MOV.W #512,r14");
> asm(" MOVX.A 8(SP),r15");
> asm(" CALLA r15");
>
> Cheers,
> Chris
> --
>
> Start a New Thread

Hi,

> I'm working on a project for the 4618 and ran into a similar problem.
> At this point (I was searching back in content in search of another
problem I'm
> having) you may have already discovered this, but the error you're having
is the
> result of a silicon error in the 2618. This is straight from the 2618
errata
> (http://focus.ti.com/lit/er/slaz033a/slaz033a.pdf):
>
> CPU7 CPU7 - Bug description
> Module: CPU, CPU CALL, and PUSH instructions
> CALL and PUSH instructions using @SP+, @SP, and X(SP) addressing modes
> behave differently from original CPU. The original CPU predecremented the
SP then used the
> predecremented value to calculate the address. The new CPU uses the SP to
calculate the
> address, then decrements it.
> Workaround: (Fixed in the compiler for C source. No silicon fix planned.)

This is *not* a correct characterisation of the CPU7 bug. Really. TI need
to update the buggy errata to *correctly* describe the bug. The fact CCE
doesn't work around it just means CCE is a ball of old tar. Sorry, couldn't
resist. ;-)

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors Start a New Thread

Colin,

I'm working on a project for the 4618 and ran into a similar problem. At
this point
(I was searching back in content in search of another problem I'm having)
you
may have already discovered this, but the error you're having is the result
of
a silicon error in the 2618. This is straight from the 2618 errata
(http://focus.ti.com/lit/er/slaz033a/slaz033a.pdf):

CPU7 CPU7 - Bug description
Module: CPU, CPU CALL, and PUSH instructions
CALL and PUSH instructions using @SP+, @SP, and X(SP) addressing modes
behave differently
from original CPU. The original CPU predecremented the SP then used the
predecremented value
to calculate the address. The new CPU uses the SP to calculate the address,
then decrements it.
Workaround: (Fixed in the compiler for C source. No silicon fix planned.)
None.

CPU8 CPU8 - Bug description
Module: CPU, using odd values in the SP register
The SP can be written with odd values. In the original CPU, an odd SP value
could be combined
with an odd offset (i.e., mov. #value, 5(SP)). In the new CPU, the SP can be
written with an odd
value, but the first time the SP is used, the LSB is forced to 0.
Workaround:
Do not use odd values with the SP.

In my project I was able to get around the problem using inline assembly :

ramFunc = (_ramFunc_ptr)(EXEC_RAM);

// ramFunc( bufAddr, ramBuff, 512 );
asm(" MOVX.A &bufAddr+0,r12");
asm(" MOV.W #ramBuff+0,r13");
asm(" MOV.W #512,r14");
asm(" MOVX.A 8(SP),r15");
asm(" CALLA r15");

Cheers,
Chris
-- Start a New Thread

Hi,

Just for fun I dropped the code into Borland C/C+ with Codeguard enabled
just to check for any sillies ...

It runs fine there too.

Obviously delay2 is never called 'tho.

Richard

----- Original Message -----
From: Colin Garland
To: m...
Sent: Thursday, December 20, 2007 2:53 AM
Subject: [msp430] CCE V2.0.4.2 Function Lookup Table
First posting to this news group...

I'm migrating to MSP430F2618 from MSP430F149 to take advantage of
extended Flash area (120k) and RAM (8K). Unfortunately as GNU didn't
support 20Bit address mapping so I've had to use resort to either IAR or
CCE compiler. I like the feel and cost of CCE but for this one issue
that might put me back to using IAR. I have a CCE compile bug which I
can't solve and wonder if this news group had any ideas? I'm trying to
do Function Lookup Table and CCE works fine in 16bit Addressing mode but
not 20bit (silicon_version = mspx) mode. IAR executes the code fine.

When CCE execute the task(); causes the code to jump into la-la land and
reset itself. Start a New Thread

First posting to this news group...

I'm migrating to MSP430F2618 from MSP430F149 to take advantage of
extended Flash area (120k) and RAM (8K). Unfortunately as GNU didn't
support 20Bit address mapping so I've had to use resort to either IAR or
CCE compiler. I like the feel and cost of CCE but for this one issue
that might put me back to using IAR. I have a CCE compile bug which I
can't solve and wonder if this news group had any ideas? I'm trying to
do Function Lookup Table and CCE works fine in 16bit Addressing mode but
not 20bit (silicon_version = mspx) mode. IAR executes the code fine.

When CCE execute the task(); causes the code to jump into la-la land and
reset itself.

The simplified code is:

#include "msp430x26x.h"

void delay(void);

void delay2(void);

typedef void (*DELAYFUNC)(void);

const static DELAYFUNC taskDelayTable[] = {

delay,

delay2,

};

void delay(void)

{

volatile unsigned int i; // volatile to prevent
optimization

i = 10000; // SW Delay

do i--;

while (i != 0);

}

void delay2(void)

{

volatile unsigned int i; // volatile to prevent
optimization

i = 20000; // SW Delay

do i--;

while (i != 0);

}

void main(void)

{

DELAYFUNC task;

WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer

DCOCTL = CALDCO_1MHZ;

BCSCTL1 = CALBC1_1MHZ;

for (;;)

{

P1OUT ^= 0x01; // Toggle P1.0 using
exclusive-OR

task = taskDelayTable[0];

task();

}

}

Any ideas? Or IAR the only way to go?

Colin Start a New Thread