This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
I've been working these weeks to find a bug in a msp430 piece of firmware. It finally turned out that there was a unhappy branch to a hard-coded adress that was supposed to be filled with executable code : instead of that, there were only initialisation values for some registers.
By reading the datasheet I would have expect that the Reset Interrupt would be raised for any illegal instruction fetch.Instead of that, this values have been interpreted as opcodes and instructions, although some of them were cleary not in the instruction map.
It seems that the values were decoded like if they were from CPUX instruction set, although the micro is a MSP430F123 and should not implement it. Would it be possible that the fetch/decode part of MSP hardware would decode these values as CPUX instructions, even if the actual chip does not support it ?
For instance, here are some examples taken from IAR disassembly, that should be illegal opcodes for my MSP :
0100 bra @SP
0029 012A mova &FCTL2,R9
Plus, the actual behavior does not fit with these instructions decoding, the chip does something else. (for instance not a branch to @SP, but a "push PC"...) Is there somebody from TI (or anywhere else) that could confirm how the decoding really works in such cases ?
We already have fixed this bug to avoid such a situation, but we really have to understand what's going on inside the chip to minimize any risk out there.
Thanks a lot for your help.
The maily orthogonal structure of the MSP doesn't know many 'illegal' instructions.Easch isntruction word is a combinationof isntruction and parameters, even if this combination doesn't make sense in some cases.
BRA @SP, as your disassembler shoews it, is actually an alias for a MOV instruciton with PC as target.
So BRA @SP is actially a MOVA @SP, PC. Whose instruction code, surprise, is 0x0100. Well, thsi instruction moves the value above top of stack to PC, which doesn't make much sense, but it is a valid instruction.
the second instruction, MOVA &FCTL2, R9, is a totally valid operation too. It takes a 32 bit value from memory location FCTL2 and moves its lower 20 bits into R9.
MOVA instruction is available on MSP430X cores only, but the disassembler doesn't know whether you have an MSP430 core or MSP430X core.
Time to say goodbye - I don't have the time anymore to read and answer forum posts. See my bio for details.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.I'm sorry that I can no longer provide help in the forum or by private conversation.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Jens-Michael Gross:
Thanks a lot for your answer.
The micro I'm using is a MSP430F123 (8KB Flash / 256B Ram). It does not support CPUX instruction set.
I understand that the disassembler (IAR) can be decoding something that is different from the CPU itself (although IAR knows it's a F123 and should decode accordingly...)
I checked the User's Guide for x1xx Family (SLAU049F) and did not find anything about illegal instruction fetch. It was in the x2xx Family User's Guide (that I'm using on other projects) that I saw that the Reset could be raised from illegal instruction fetch. I didn't notice this difference before, I'm using F2350 chips most of the time.
So I guess that there is no way to know what the CPU would do with illegal opcodes ? Except that it would "do something" in an unpredictable way.
What I was trying to figure out, was why some of the products would suffer from that bug, and some other wouldn't. That is, every time the CPU would go through these instructions, it would end up jumping to an address in the 0x9600 range for some products, or in the 0x2200 range for some others.Both are pointing to nowhere, there is physically nothing on this F123 between 0x1100 and 0xE000, but at the end, those that had jumped to 0x960C would get stuck and need a hardware reset (which is not possible on finished products because of potting + soldered cover) , whereas those that had jumped to 0x2200 would finally find their way back to the real code and continue execution.
What really makes the difference between the 2 cases could be some registers values, or Ram values, that could change the way these illegal instructions are interpreted by the CPU. Funny thing is that unpredictable execution is very repeatable : several products (same hardware, same firmware, same lot) in the same state behave exactly the same way. I just don't know exactly which register or value makes the difference at the end.
That was more for the context - I think there is no way to go further in the root analysis.
Except if some guys know deeply how the instruction decoding is done in the CPU ?
(TI developers ?)
In reply to Sébastien Dubail:
Sébastien Dubailalthough IAR knows it's a F123 and should decode accordingly...
Sébastien Dubail checked the User's Guide for x1xx Family (SLAU049F) and did not find anything about illegal instruction fetch.
Sébastien DubailSo I guess that there is no way to know what the CPU would do with illegal opcodes ? Except that it would "do something" in an unpredictable way.
Sébastien DubailThat is, every time the CPU would go through these instructions, it would end up jumping to an address in the 0x9600 range for some products, or in the 0x2200 range for some others.
However, the important question is: why does your MSP reach this instructions at all? It never should. So you have a bug in your code. If you fix it, the whole issue becomes unimportant.
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. 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.