MSP430G2553: Jump out of range

There is no "neat trick" to squeeze an arbitrary 16-bit address together with an instruction opcode into a single 16-bit word. (See the pigeonhole principle.)

Just use the "BR #address" instruction, which indeed is a shorthand for "MOV #address,PC", and which uses two words.

But why do you have BSL password problems? To rewrite the entire flash, you don't need the password, and you can disable the erase-on-wrong-password feature, and for debugging, JTAG/SBW would be more suitable.

Clemens Ladisch said:

But why do you have BSL password problems? To rewrite the entire flash, you don't need the password, and you can disable the erase-on-wrong-password feature, and for debugging, JTAG/SBW would be more suitable.

Thanks very much for your reply.

This is my first adventure with BSL, so I may not understand it, and perhaps you can help.  The basic problem is that in this project there will probably be a number of firmware versions which may be written by different authors, and the ultimate users will be "civilians" who will be able to jump among these versions to try them out.  It's not a case where all devices are to be updated to the latest version, at least not at first.  So the password problem is in knowing what version the user is changing *from*, and the need to maintain a password file for each version.  Of course all this could be avoided if all users were required to buy Launchpads and use JTAG, but I just wanted to avoid that if possible by embedding a much less expensive CP2102 and USB jack on the project board.  Then the only hardware they would need to flash new firmware is a USB cable.

I thought a solution would be to make the interrupt vector table at 0xFFE0, and hence the password, the same for all versions by having those vectors point to a jump table which would point to the real service routines.   Only the contents of the jump table would change from version to version.  I would be happy to consider any better solution.

But I may be confused about the mass erase issue.  I understand that with a null word at 0xFFDE, the erase-on-wrong-password feature will be disabled.  But what about the mass erase command?  My understanding is that even with the null word at 0xFFDE, the mass erase command still would erase the calibration data in INFOA, and that's the command I would have to use to get to all FF's.  To preserve INFOA, I would have to use segment erase commands, which of course are password protected commands.  Am I wrong about that?  Is there a way to erase everything except INFOA without knowing the password?

embedding a much less expensive CP2102 and USB jack on the project board

Would that be less expensive than using a MSP430F55xx with the USB BSL?

the mass erase command still would erase the calibration data in INFOA

Section 2.4.4.4 of MSP430™ Programming With the Bootloader (BSL) (SLAU319) says:

BSL versions V2.01 and higher support automatic clearing of the LOCKA bit protecting information flash memory. When the BSL is entered from a reset condition, LOCKA is cleared by the BSL to mass erase the flash, including information memory. When the BSL is entered in-application, user software should ensure that LOCKA is written as 1 prior to initiating the BSL. Otherwise, information flash is not erased during a BSL mass erase.

This sounds as if you could just ensure that LOCKA is set (i.e., don't toggle it) before entering the BSL.

Clemens Ladisch said:

embedding a much less expensive CP2102 and USB jack on the project board

Would that be less expensive than using a MSP430F55xx with the USB BSL?

the mass erase command still would erase the calibration data in INFOA

Section 2.4.4.4 of MSP430™ Programming With the Bootloader (BSL) (SLAU319) says:

BSL versions V2.01 and higher support automatic clearing of the LOCKA bit protecting information flash memory. When the BSL is entered from a reset condition, LOCKA is cleared by the BSL to mass erase the flash, including information memory. When the BSL is entered in-application, user software should ensure that LOCKA is written as 1 prior to initiating the BSL. Otherwise, information flash is not erased during a BSL mass erase.

This sounds as if you could just ensure that LOCKA is set (i.e., don't toggle it) before entering the BSL.

I've never looked at any MSP430s with USB, so I don't know about that option. At this point we're looking at a through-hole board with a DIP processor.  The CP2102 would be added in the form of a pre-soldered module mounted on the board, which costs $1.45.

As of now, BSL would be entered by connecting the USB cable and providing the BSL entry pattern on /RESET and TEST.  I believe that would be entering from a reset condition.  So I would have no way to do anything before BSL starts.  I've never been clear how I would enter BSL from my application.  Do I just jump to 0x0C00?

Table 21 of SLAU319 shows how to do a software call to the BSL.