MSP430G2231: Triggering flash erase - assembler mystery

Hi Goerge,

adding to your analysis and Andre's which is correct: the bit value has to be assigned with "#" instead of "&".

Why the bootloader is working, because this wrong sign assignment is only on the Erase Segment function. It does not impact the programming part.

Thanks for the replies.  I've confirmed that the erase IS performed using the bad instruction, at least on my G2231s.  And it looks like the error has been there for a long time, and if it didn't work someone would have mentioned it.  I searched all the files in the ZIP for occurrences of "&FWKEY", and that only appears in the CCS and IAR code for v5 and v7 of the G2xxx parts.  So four files in total. 

One explanation might be that when reading a non-existent location, at least in the A5 range, the address is returned as the contents value.  If I have time, I'll try to test that.

Andre Frantzke said:

Hi George,

do you have further questions to this topic? If not, I will close this thread.

Thanks,
Andre

Well, I was hoping for an explanation.  SLAU144 says if the high byte isn't FWKEY, the processor will reset.  And that clearly isn't happening. But it isn't important.  I just wondered how a completely wrong instruction could work in this situation.  If no one has an explantion, you can close the thread.

Andre Frantzke said:

Hi George,
this error was never seen, as the "Erase Segment" function is not used by the boot loader. Only the "Mass Erase" is used. We will fix this in future releases. Thanks for highlighting it!

Best regards,
Andre

That doesn't appear to be correct.  The bootloader doesn't use Mass Erase at all.  There is no occurrence of "MERAS" in those files.  Instead, it ERASEs MAIN memory one segment at a time.  I don't know why it does that, but that's what it does.  Moreover, the incorrect instruction is used for each segment erase, and works perfectly each time.

When I wrote my own version of this, I switched over to mass erase, but, not paying attention, otherwise copied that part of the code, including the bad instruction.  And my code worked perfectly too.

But I think I've found the explanaton for why the bad instruction works.   I wrote a short test program that duplicates the bad instructions as follows:

    mov.w    &(FWKEY + ERASE),  &0x0200        ;Duplicate the coding error
    mov.w    &(FWKEY + MERAS),  &0x0202        ; see what's written to RAM

These lines move the contents of locations 0xA502 and 0xA504 into RAM even though there's nothing at those locations. This is exactly what the bad BSL instruction did.  Then using correct instructions I copied the contents of the RAM locations to the bottom of INFOD, then exited.  Later, reading in the contents of INFOD with the command line flasher, I got this IntelHex:

:20 1000 00 02A504A5FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF9C

So the explanation appears to be that, at least for the 0xA5xx range of locations, if you read the contents of a location at which nothing exists, the location address itself is returned as the contents of that location.  That means "&FWKEY+ERASE" has the same value as "#FWKEY+ERASE".  And that's why it works.  And actually you don't need to fix it except for appearances.

And apparently for G2xx as well.  Well this explains it.  Thanks very much.