MSP430F5438 problem with MOVA instruction

Actually your observation is what I would expect if there weren't the erratum CPU16 (which actually is no erratum but just a duplication of the description of the indexed mode in lower 64k, chapter 4.4.2.1).

Normally, I'd expect that the above command will subtract 0x5b4a from R15 (the index is signed). Which is, as it is a 20 bit calculation, 0xfa4bc. Of course there is no flash and the reading would be 0xf3fff as one could expect when reading from a vacant memory location (2* 0x3fff, the default return value).

Yet if the register has the upper 4 bits clear, the result should be truncated to 16 bit and the addressed location should be 0x0a4bc, which is of course no vacant space.
So either CPU16 and the users guide is wrong or something else is going on.

Are you sure that you have an MSP430F5438 and not an XMS430F5438? The XMS devices are premature demo versions and often differ from the docs.

Also, what you observed will happen if the code is executed in ram while the flash controller is busy writing or erasing. Then it will return 0x3fff to any request. The memory dump will of corse reveal the correct contents as it is taken when the flash controller is no longer busy.

What you can try is to change the instruction to
mova 0x0006(R15), R15
where R15 is loaded with 0xa4b6 before. Here 6 is added to R15, giving the expected 0x0a4bc address in any case.

While normal programming experience leads to the assumption that the register contains the variable offset to a fixed address (such as an array base address), the assembly language description tells that the fixed part is the (signed) offset and the register contains the base address.
This makes no difference on a plain 16 bit system due to the automatic rollover, but it does when the address range is larger than 16 bit and no rollover happens.
Note that the MOVX instruction has a 20 bit offset part, so the automatic rollover applies again.

Thanks, Jens-Michael

Jens, reading your last post,  this thread again and then the manual and the CPU16 errata, I find that I was wrong. Indexed register addressing has different behaviors indeed based on the base register bits 16:19 being null or not for simple instructions (4.4.2.1) but supposedly not if the instruction is an address instructions indexed mode (4.4.2.4) as you  pointed out.  I see too now that for the original example in this thread  mova   0xA4B6(R15), R15, the result found by the user based on R15 content after execution seems to be for address 0xFA4BC ; what you'd expect for an address instruction if there weren't the erratum cpu16.  cpu16 errata states that " if the register content is <64k it is not possible to reach memory above 64k". Put it simply, cpu16 is describing the bug as address instruction indexed mode wrongly behaving like simple adress indexed mode, which it isn't in this example. 

Sometimes describing a bug can make incorrect simplifications when trying to understand its modus operandi. The bug must not be fully understood. You are saying that the wrap around behavior follows cpu16's description (unwantingly wrapping around on 64K) when register <64k +index would exceed 64k but that underflowing the register follows the user manual wrapping around 1024K (1M). Based on these observations, cpu16 might be rewritten as follow (unless I make a mistake)

a) if the register address is below 64k the register is sign extended from 16 bits to 20 bits and added to the signed index extended to 20 bits. Or using a casting and sign extension notation :

adr =  (X .W)->.A +  (R).W->.A   

b)  If the register address is >= 64k then the index is sign extended to 20 bits and added to the register :   

adr = (X.W)->.A + R

example1 : mova A4B6h(R5), dst   with R5=00006h  gives source address  (A4B6h)->.A + (00006h).W->.A = FA4B6h + 00006h = FA4BCh  (underflowing the register when <64k wraps around 1M)

example2:  mova 0006h(R5) , dst   with R5=0FFFEh gives source address  (0006h)->.A + (0FFFE).W->.A = 00006h + FFFFEh = 00004h (exceeding 64k when register <64k wraps around 64k) 

example3: mova 0006h(R5), dst   with R5=1A4B6h  gives source address  (0006h)->.A + 1A4B6h = FA4B6h + 00006h = 1A4BCh  ( register >64k  ) 

example4:  mova 0006h(R5) , dst   with R5=FFFFEh gives source address  (0006h)->.A + FFFFE = 00006h + FFFFEh = 00004h (overflowing the register wraps around 1M) 

I think this pretty much sums it up.

I'd say, the safe way is to use the MOVX instruction rather MOVA for indexed addressing. It is a word longer but does what it is intended to do if you operate in extended address space, while the good old MOV is sufficient if you want to remain in the lower 64k.

The orthogonal design of the MSP430 instruction set made it seem mandatory to implement indexed mode for MOVA, but due to the inherent ambiguity of the parameters (which cannot be detectred/resolved at compile time) it shouldn't be used. The TI engineers tried to resolve the ambiguity problem, but every attempt to do so that succeeds in one case will inherently cause failure for the other. And so did the solution they implemented.
In their situation, I had dropped MOVA z16(R) (and the opposite MOVA R,z16(R) ) totally. Every tool that can handle MOVA instructions can also as well use MOVX.

BTW, CALLA x(R) also fails miserably if x is >0x7fff. Early versions of the MSP430X compilers used this when calling a function through an indexed function pointer array (e.g. call function #X from a dynamically loaded library with a jumptable above 0x8000)  EDIT: looking back, it was too MOVA, not CALLA (which doesn't have indexed mode at all) that was used by the compiler in this case - and failed.

MOVX x(Ri), Rj  is 1 cycle slower than MOVA x(Ri),Rj  it is a convenient choice nevertheless.

one might never use a C or C# compiler but only MSP430 assembly language tools (assembler, linker, archiver, etc). Bugs like cpu16 make using a compiler even less attractive. Wasted time on a compiler to do guesswork what the compiler will do / has done and why - is time lost on one's own code. Since it is embedded application the closer to the hardware will be the most robust and transparent to the programmer.

For this bug it seems  the only case that would lead to a practical application failure (you mentioned dynamically loaded library) is when the register is between 0x08000 and 0x0FFFF. With MOVA x(R)  the index x is always sign extended to 20 bits (bug or not) and therefore should never be made to contain the base address as you pointed out (which this thread original example seems to be doing). But suppose one is coding in assembly language (no compiler) then one could circumvent this by restricting x <= 0x7FFF (extension to 20 bits stays unchanged) and the register serves as a positive or negative 20bits index it would either be looking like 0xFxxxx or 0x0xxxx. That still has potential for bug failure on positive values  > 0x07FFF. This is because the bug is apparently sign extending R a15..a0 to 20 bits (example2) resulting in the 64k wrap round 64k that one is not expecting with MOVA x(R). So then the only absolutely safe choice within practical uses -unless i am making a complete reasoning mistake which is possible :)- , would be for R to avoid the address section from  0x08000 to 0x0FFFF when using MOVA.

This thread original example demonstrates the underflow behavior of the true bug (that cpu16 is missing) but remains a bad use of MOVA with the base address apparently held in the index instead of the register.  You pointed that out right from the beginning. I think this leaves the only practical case for the bug  (with no user error) where R is between 0x08000 and 0x0FFFF. 

Completely unrelated.. why is indirect with auto-increment address mode @R+ no longer available for the destination register on MSP430 ? I was reading an earlier coding hints note and saw lines with MOV  x(Ri), @Rj+. Could it be that doing an explicit add  ADDA  #00001h, Rj  was deemed an acceptable alternative speedwise ?  BTW can one write the constant values generator addressing modes directly when using an assembler  (let's forget the compiler altogether) ? for example :

MOVA R3, Rj for MOVA #00000h,  Rj   or   MOVA @R3+, Rj  for ADDA #FFFFFh, Rj   ?

Yes, MOVX is a word longer, so it is a cycle slower.

If this is important (to most of the MSP users it isn't, especially not to those who use float variables where integers would be sufficient, such as index counters), then you'd use assembly or at least inline assembly.

I once worked in espire (an object.oriented assembler language) and did assembly work for the C64, Spark and the 8031 processors. But for more complex tasks I prefer high-level languages. Today, most compilers produce assembly output anyway instead of producing binary code directly.

Nevertheless, unless you are have a toolchain where the assembler directly produces the final output, or you do additional effort for exact segment placing, you'll never know where the code ends up in memory space. That's not a matter of using compiler or assembler, but it is the linker that puts the code in place. So the critical instruction may well end up where you don't want it (>0x7fff), no matter whether you use compiler or assembler. So you can't easily prevent the immediate part from becoming >0x7fff and depending on your application, it might not be possible to ensure the register stays below 0x7fff as well. Even though this is rather unlikely, as most people don't use tables >32k. Well, To be true, I once did, on a 1611 with 40k ram. This code couldn't work on any MSP430X while using MOVA.

Using the immediate index as base and the base address register as index is what was always done when the address space was limited to 16bit. It didn't make a difference. And that's understandable, because you usually have a fixed base address and a variable index. However, the MSP core was designed the opposite way. Maybe due to internal optimizations. I don't know. Only the original designers know.
 When going to 20 bit address range, this didn't work anymore. Sometimes you have to pay the price for additional functionality. Such as using MOVX for having more than 64k memory.
The user's guide states: "address instructions are instructions that support 20-bit operands but have restricted addressing modes." and  "Restricting the addressing modes removes the need for the additional extension-word op-code". That's true. However, the restrictions obviously extend beyond just not providing some addressing modes. IMHO it would have been better to simply not provide the indexed mode at all. Especially since MOVA is the only one providing it.

To answer you other question regarding indirect register/autoincrement for destination: this was never part of the MSP instruction set. The orthogonal structure of the instruction word leaves only 3 bits for the source and destination addressing modes. Since immediate value for destination makes no sense, two bits were assigned for the source and 1 bit for the destination, In fact, there are only 4, not 7, different addressing modes: Register, indexed, indirect registrer and autoincrement.
Immediate mode is implemented by using autoincrement mode on PC register, absolute is implemented by using indexted with SR (= constant generator returning 0) and symbolic is done as indexed on PC.

Using constants will take same cycles as with registers, regarding 16-bit instructions. With 20-bit instructions, number of cycles can be different.

        adda R4, R5        ; 1
        adda #0, R4        ; 2
        adda #1, R4        ; 2
        adda #2, R4        ; 1
        adda #4, R4        ; 2

        suba R4, R5        ; 1
        suba #0, R4        ; 2
        suba #1, R4        ; 2
        suba #2, R4        ; 1
        suba #4, R4        ; 2

        cmpa R4, R5        ; 1
        cmpa #0, R4        ; 1
        cmpa #1, R4        ; 2
        cmpa #2, R4        ; 2
        cmpa #4, R4        ; 2

zrno soli, that would be a let down for address instructions. What is your source and what about mova ? mova with true immediate source takes 2 cycles. Though your syntax is relying on the compiler you did not spell out use of the constant generator but the quoted cycle times are quicker than true immediate to register (3 cycles for adda, suba and cmpa) so I assume the compiler made the proper substitutions.

I was working on algorithm in assembler that was using 20-bit data and was cycle aligned. I noticed some strange things, and measured number of cycles for each assembler instruction. At the end, everything was running fine. I forgot mova in last post, here it is...

        mova R4, R5        ; 1
        mova #0, R4        ; 2
        mova #1, R4        ; 2
        mova #2, R4        ; 1
        mova #4, R4        ; 1

Jens-Michael Gross said:

On slower MCLK, no waitstates apply and things are like with the flash-based MSPs.

My assembler cycle aligned code executed on any 2xx / 5xx I tried without problems. I was surprised that it failed on FRAM, even it was on low MCLK (1 MHz) without wait states. To save some space I used JMP $+2 instead of double NOP's, and that was the problem. When I replaced back all JMP $+2 with double NOP's it started to work on FRAM, too.

I measured instruction cycles with timer, for all instructions without cycle number noted inside family datasheet, and some that I have doubts. Noted on side, for later use. I also measure number of cycles for executing some part of code, that was not as per datasheet, to clear up things. For example (if I remember right) this two blocks on 2xx will take 24 cycles, but not on 5xx, where instruction order have impact on number of cycles.

    rra.b @R5         ; 3        rra.b @R5         ; 3
    nop               ; 1        rra.b @R5         ; 3
    rra.b @R5         ; 3        rra.b @R5         ; 3
    nop               ; 1        rra.b @R5         ; 3
    rra.b @R5         ; 3        rra.b @R5         ; 3
    nop               ; 1        rra.b @R5         ; 3
    rra.b @R5         ; 3        nop               ; 1
    nop               ; 1        nop               ; 1 
    rra.b @R5         ; 3        nop               ; 1
    nop               ; 1        nop               ; 1
    rra.b @R5         ; 3        nop               ; 1
    nop               ; 1        nop               ; 1
-------------------------    -------------------------
Total number of cycles 24    Total number of cycles 27

@Jens Michael Gross

The user manual gives a binary description of extended instructions (4.6.1) . All MOVA combinations independently of addressing mode for source and destination occupy 1 word, This appears to put a contradiction between cycle counts measured by zrno soli timer approach and the assumption :"instructions that take 2 cycles should also be 2 words long." Looking at that binary description table for MOVA closely the usual As bits 5:4 and Ad bit 7 position values given are not what one would expect for the addressing opcode when compared to non-address instruction binary description (table 4.22). You must be right that it does not have the normal As and Ad fields. On the other hand it is not missing  MOVA Rsrc,&abs20, which appears in the table.  

@zrno soli

Have you tried to time non-extended instructions (MOV, ADD, SUB, CMP) ? Since they do not have the same addressing restrictions imposed on xxxA instructions it would clarify a few things. I expect 1 cycle MOV for all constant listed in the constant generator to a register destination, but if not, definitively for R3. If you do not get 1 cycle for MOV #0 , Rdst, there could be something else going on with the timer approach.

The manual says NOP is an emulated instruction for MOV #0, R3. In the CGR section it also says quite contradictly : " Registers R2 and R3, used in the constant mode, cannot be addressed explicitly; they act as source-only registers". This is equivocal for MOV #0, R3. Then they also say it can be used to set defined waiting time and never give cycle times for CG source.

Howard Handsum said:

Have you tried to time non-extended instructions (MOV, ADD, SUB, CMP) ? Since they do not have the same addressing restrictions imposed on xxxA instructions it would clarify a few things. I expect 1 cycle MOV for all constant listed in the constant generator to a register destination, but if not, definitively for R3. If you do not get 1 cycle for MOV #0 , Rdst, there could be something else going on with the timer approach.

The manual says NOP is an emulated instruction for MOV #0, R3. In the CGR section it also says quite contradictly : " Registers R2 and R3, used in the constant mode, cannot be addressed explicitly; they act as source-only registers". This is equivocal for MOV #0, R3. Then they also say it can be used to set defined waiting time and never give cycle times for CG source.

As already noted...

zrno soli said:

Using constants will take same cycles as with registers, regarding 16-bit instructions. With 20-bit instructions, number of cycles can be different.

16-bit instructions regarding number of cycles (with using constant generator or not) are like in datasheet. MOV.W #0, R4 will take one cycle. If you have doubts about my measurement you can check by yourself.

As I see in 5xx /6xx family manual NOP is emulated by MOV R3,R3.

That's right you said that earlier, i forgot.  Still, strange things are happening with your results and you seem to demand absolute faith in your word without submitting code to peer analysis or at least a sufficient verbal description of your cycle alignment method (  timer mode, timer initialization, interruption(s) , etc) . In such conditions people are left with having to trust you or not  because you said so which is not a constructive or useful situation to fill the gaps in the user manual. Your results may very well be correct, that is not the point here.

I can't attach source, because my USB assembler stack is part of this. Program print number of cycles on PC serial (CDC) terminal.

Algorithm for measuring number of cycles don't use any interrupts.

1) clear and start timer as counter clocked by (S)MCLK

2) execute 256 times mov.w R5, R6 (one instruction or part of assembler code, copied 256 time, no looping)

3) stop timer

4) number of cycles will be stored in higher byte of timer register (TAxR). Few cycles used for stopping timer are irrelevant, related to (at least) main 256 cycles.

Howard Handsum said:

The manual says NOP is an emulated instruction for MOV #0, R3.

zrno soli said:

As I see in 5xx /6xx family manual NOP is emulated by MOV R3,R3.

Since #0 is emulated by R3 in registe rmode, this is the very same.

Howard Handsum said:

Registers R2 and R3, used in the constant mode, cannot be addressed explicitly; they act as source-only registers"

Well, R2 in register mode is the status register. It can be read and written in this mode. In all other modes it is write protected and reads the constants. R3 might be writable, but since it always returns #0 in register mode (and othe rconstants in othe rmodes), it would be a write-only register :)

The MSP430 does not throw an exception if an instruction is used in an illegal way. The memory controller throws an exception if instrucitons are fetched form vacant memory or such, but not the processor. It silently ignores the illegal state, continuing as if it were legal. If you use word instrucitons on an odd address, it silently ignores the LSB. If you write to R3, it will silently ignore that R3 can't be written to. Or at least that this won't have an effect - I guess that R3 very well exists physically, like all other registers (straight design), even though you cannot by any means read it. Likely, the difference would be in the access signal logic.