crash with indexed CALLA instruction from flash

Hi Jens,

Really good post, I say.  Seems pretty clear you have a silicon bug on your hands.  I've never seen that one documented before.

Hey TI, somebody needs to look at this one.

I guess I'm not too surprised that nobody has ever found it before.  It is an odd thing to have a const array of function pointers.

The workaround should be simple even if you leave the table in flash.  Please post again if you can't seem to work around it.

Jeff

Very nice catch, JMG. No silicon bug after all.

I believe the OP Jens said his compiler generated this code, so I think you found a bug in CCS.

What makes this so strange is that it's a 20-bit instruction with only a 16-bit index!  Only CALLA and MOVA are like that.  All other 20-bit instructions use a 20-bit index for indexed-mode addressing.  It's a little bit confusing.

So would MOVA 0xC272(R15), xyz  still read from the wrong address like CALLA ?

Jeff

Actually, CALLA, MOVA and RETA are the only instruciton dealing with 20 bit address range (except for plain register/register instructions) but not having the Prefix word that stores the upper 4 bits of 20 bit arguments.

For MOVA, you can use MOVX.A and get a 20 bit argument. At the cost of an additional cycle and an additional instruction word. (well, better than having 32 bit operands)

I guess, nobody thought that a CALLX.A instruction would be needed.

However, the OP didn't say anything about compiler, and the code looks like hand-crafted assembly. I don't think the compiler will generate a jumptable like this. And the linker just links what is given to it for linking.

There are several other ways to do it. Use MOVX.A (not MOVA) to load the target address into R15, then CALLA R15. Or call the jumptable itself directly. The table is preceded by an  ADD R15, PC,  and the jumptable contains branch instructions, not just addresses. And more.
I agree, that the probelmatic way is the most obvious. But unfortunately a non-working one if the table is above 0x8000.

Jens Potschadtke said:

I use the CCS  Version: 4.1.3.00038  and use the CCS compiler. The original code is in C.

I think this really is a CCS bug.

I'm guessing the OP has a const array of function pointers.  I'm guessing when he removes the "const" his code works just fine.

Also, because RETA is really just MOVA @SP+, PC, it really is just the two instructions CALLA and MOVA that are limited this way.  They are 20-bit instructions, but when using indexed addressing they use only a 16-bit index.  They are the oddballs.  As JMG pointed out, MOVX.A provides full functionality, but there is no CALLX.A, so one must restructure the code.

Jeff

Jeff Tenney said:

I use the CCS  Version: 4.1.3.00038  and use the CCS compiler. The original code is in C.

[/quote]Well, my eyes aren't getting better by staring at other people's code :)
I didn't see this even when I was specifically lookign for it.

Well, the original code would be interesting.

Jeff Tenney said:

I think this really is a CCS bug.

Yes, it if was C code then indeed this is a bug in large code model (small code model won't use CALLA, and for CALL it works)

Jeff Tenney said:

I'm guessing when he removes the "const" his code works just fine.

Definitely, as the array then is copied to ram and I don't know any MSP with RAM above 0x8000 :)

Jeff Tenney said:

there is no CALLX.A, so one must restructure the code

Yep. A possible restructuring is to separate the function call from the table by first fetching the destination into a variable and then doung the call using the already fetched variable. However, compile roptimization might undo this workaroun (sometiems, compilers can be too smart)

Hello,

it`s me again, back from a short vacation around easter holidays.

After all those explanations in this thread I think it is really a CCS bug.

The C-compiler and linker should be aware about the limitation of using an indirect offset bigger than 0x8000 in a CALLA instruction results in a negative sign extended address value. So either it should prepare the index register accordingly to offset this effect or use any of the other proposed workarounds.

Just removing the "const" from the table places it in RAM at lower addresses, so the error does not appear.

When I want the table in ROM, then I will use an additional step and hope that the compiler does not optimize the code too much. I didn't have the time yet to try this out, since at the same time I was chasing down a rare DMA error, which corrupted exactly this jump table in RAM. But that is an other story and I seem to have found my error there by now.

I will try to produce a small sample code snippet. The current code is part of a larger state machine.

Greetings,

Jens

Hi Jens,

As JMG mentioned, you can select the small code model in CCS (if they still support it).

That should make a nice work-around for your problem until they fix the bug.  In the small code model, CCS uses CALL instead of CALLA.

Jeff

Jens-Michael Gross said:

...

I think this really is a CCS bug.

Yes, it if was C code then indeed this is a bug in large code model (small code model won't use CALLA, and for CALL it works) ... [/quote]

Are you sure it won't use CALLA in small code model? (I do not have nor want to have CCS.)

Jens-Michael Gross said:

...

I'm guessing when he removes the "const" his code works just fine.

Definitely, as the array then is copied to ram and I don't know any MSP with RAM above 0x8000 :) ... [/quote]

The OP showed code at 0x82xx and table at 0xC2xx (does not work). He also showed code at 0x8200 and table at 0x28xx (works). CC430F6137 has Flash from 0x8000 to 0xFFFF and RAM from 0x1A00 to 0x2BFF.

Based on what the OP said, I must conclude that there is a hardware bug. I do not think the c-compiler caused the crash in this case.

• Cancel

• Up 0 True Down
• Cancel

Jeff Tenney said:

Hi Jens,

As JMG mentioned, you can select the small code model in CCS (if they still support it).

That should make a nice work-around for your problem until they fix the bug.  In the small code model, CCS uses CALL instead of CALLA.

Jeff

That chip has only 32 KB Flash below 0x10000. Can he use large code model in CCS?

old_cow_yellow said:

That chip has only 32 KB Flash below 0x10000. Can he use large code model in CCS?

Yes, I think so.  Somewhere I heard that CCS defaults to the large code model for any MCU with CPUX.  It's a waste of code space, stack space, etc, on MCUs with flash only up to 0xFFFF.

Full disclosure, I don't actually use CCS either.  Just IAR.

As to the bug, I think the OP's most-recent post summarized the problem pretty well.  CCS should know that indexes larger than 0x7FFF are treated as negatives when used with CALLA.  The effective address ends up at 0xFC272 instead of 0x0C272 as intended.

Jeff

old_cow_yellow said:

That chip has only 32 KB Flash below 0x10000. Can he use large code model in CCS?

Problem is that for large and small code model, you'll have to provide different versions of the standard library, different startup code etc. THis might be the reason if you cannot switch over to small code model for these CPUs. Less variants of the libraries needed.

Jeff Tenney said:

Full disclosure, I don't actually use CCS either.  Just IAR.

Jeff Tenney said:

CCS should know that indexes larger than 0x7FFF are treated as negatives when used with CALLA.

Hello,

below is a condensed code snippet to reproduce the described error:

If one removes the "const" in the definition of functionList, then the table is placed in RAM and the error goes away.

typedef void (fsmfunct) (void);         /*  Address of FSM function          */

void func1(void);
void func2(void);

//the list of functions
//if placed in ROM, the code crashes below
fsmfunct * const functionList [] =
{
    func1,
    func2,
    func1,
    func2
};
//a dummy counter
int counter=0;

//a dummy function
void func1(void)
{
  //do something
  counter++;
}

//a dummy function
void func2(void)
{
  //do something
  counter += 2;
}


void main(void)
{
  int i;
 
  for (i=0;i<3;i++)
  {
    //call the function from the table
    (*functionList [i]) (); //crashes when table is in ROM
  }
 
}

I found the workaround, which works for me: See below.

The compiled code for calling entries from the table is now much more complicated and twice as big, but works.

void main(void)
{
  int i;
  fsmfunct *targetFunction;
  for (i=0;i<3;i++)
  {
    targetFunction = functionList [i]; //fetches address to R15
    (*targetFunction)(); //compiles to CALLA R15
   
  }
 
}

Jens Potschadtke said:

The compiled code for calling entries from the table is now much more complicated and twice as big, but works.

Normally, it shouldn't differ from the original one much.

Just one additional MOVX.A (just like I proposed). Unless, of course, the handling of function pointers in local variables is handled ineffective, using 2 16bit registers for the fetch (with MOV instructions) instead of a 20bit register, then combine them before the CALLA. But even if so, it's not a bug anymore :)

Hi Jens,

In addition to posting the assembly code, can you also tell us which data and code models you are using?  There are typically three choices for data model (small, medium, large) and two choices for code model (small, large).  The choices are buried in the IDE somewhere.

Can you also tell us if your original code works when you switch to the small code model?

Jeff

Ok, below is the assembly code of the code inside the for loop  of my workaround.

Apparently it is so complicated, since it uses a variable on the stack for holding the address.

         C$DW$L$main$2$B, C$L1:
0x0C056:   412F                MOV.W   @SP,R15
0x0C058:   065F                RLAM.W  #2,R15
0x0C05A:   1800 4FD1 C0CC 0002 MOVX.A  0x0c0cc(R15),0x00002(SP)
0x0C062:   013F 0002           MOVA    0x0002(SP),R15
0x0C066:   134F                CALLA   R15

When I use the same workaround on my real code and not the example, then the code is more efficient, since it just uses a register for holding the address. So there is not much overhead there.

These are the settings of my sample project, where I verified that the error occurs, when I don't use the workaround. So, it seems not to be the large data model but just the MSPX CPU.

This is what the all options field contains:

--silicon_version=mspx -g --include_path="D:/Programme/Texas Instruments/ccsv4/msp430/include" --include_path="D:/Programme/Texas Instruments/ccsv4/tools/compiler/MSP430 Code Generation Tools 3.2.3/include" --diag_warning=225 --printf_support=minimal

Jens Potschadtke said:

0x0C05A:   1800 4FD1 C0CC 0002 MOVX.A  0x0c0cc(R15),0x00002(SP)
0x0C062:   013F 0002           MOVA    0x0002(SP),R15

It's as I thought, the compiler doesn't use a 20bit register for the pointer, it reserves a 32 bit area on stack, first moves the data from the table to stack and then from stack to R15.

MOVX.A 0x0c0cc(R15), R15 would have been sufficient. (6 bytes, 4 bytes stack and 6 cycles less)

Or CALLA 0x0002(SP) and no use of R15 at all. (4 bytes and 4 cycles less)

I don't know whether CCS allows specification of 'register' variables? Maybe it then generates a more efficient code?

Currently, it looks as if the 20 bit support of the C compiler still requires some improvements. (same for IAR and MSPGCC).

OK,

it's good to hear that the new compiler has no longer this bug.

So, I have a reason to switch to the new CCS.

Thanks.