TI E2E Community
MSP430 Ultra-Low Power 16-bit Microcontroller Forum
crash with indexed CALLA instruction from flash
today I just discovered a strange behaviour of my code when I transfered a jump table from RAM to Flash on the CC430F6137 controller.
When the code wants to jump to an entry of the table with a CALLA instruction, it crashes (sets PC to 0x0F3FFE)
If the table sits in RAM then everything works as expected. When the same table is placed in FLASH, the app crashes.
This is the code with the table placed in ROM (at address 0xc272):
0x08226: 4F6F MOV.B @R15,R15
0x08228: 118F SXT R15
0x0822A: 065F RLAM.W #2,R15
0x0822C:> 135F C272 CALLA 0xc272(R15)
At the time of the CALLA instruction, the R15 has the content 0x10. But even with 0 the app crashes.
Coil_module = 0xc272
B372 0000 B3A4 0000 B378 0000 B37E 0000 B352 0000 B242 0000 B390 0000 B3A8 0000
The intended jump address is 0xB352, which I verified to hold the wanted function.
First I thought it is the alignment, which in this case is aligned only to 2 bytes, not to 4 bytes. But even with an alignment of 4 Bytes for the table the app is crashing.
Now, when I place the same table in RAM (here also with alignment 2), the code is working:
0x0822A: 065F RLAM.W #2,R15
0x0822C: 135F 28DE CALLA 0x28de(R15)
Now, for security reasons and for restricted RAM space, I just want to place the jump table in ROM. Is there any way to make the call work?
Is this a hardware bug? Is this documented somewhere?
Well, the errata CPU33 of the document SLAZ052J, looks similar, but is states that this is only applicable when
This erratum applies only when the instruction sequence is: PUSH orPUSHX followed by CALLA index(SP).This erratum does not apply if the PUSH or PUSHX instruction is used inthe Register or Immediate addressing mode.This erratum applies only when SP is used as the destination register inthe CALLA index(Rdst) instruction.
I use the CCS Version: 4.1.3.00038 and use the CCS compiler.n The original code is in C.
Greetings and happy easter,
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?
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,R150x0C058: 065F RLAM.W #2,R150x0C05A: 1800 4FD1 C0CC 0002 MOVX.A 0x0c0cc(R15),0x00002(SP)0x0C062: 013F 0002 MOVA 0x0002(SP),R150x0C066: 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 Potschadtke0x0C05A: 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).
_____________________________________Before posting bug reports or ask for help, do at least quick scan over this article. It applies to any kind of problem reporting. On any forum. And/or look here.If you cannot discuss your problem in the public, feel free to start a private conversation: click on my name and then 'start conversation'. But please do so only if you really cannot do it in a public thread, as I usually read all threads. And I prefer to answer where others can profit from it (or contribute to it) too.
Jens Potschadtkebelow is a condensed code snippet to reproduce the described error
Using CCS 5.1 I created a new project for a CC430F5137 and used compiler version 4.0.2 (the latest). The program ran successfully.
I changed to use compiler version 3.2.3 (the version you appear to be using). The program then crashed when attempted to single step the (*functionList [i]) ();
i.e. the crash appears to be fixed in a later version of the compiler.
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.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.