MSP430, simulate reset (for a software bootstrap loader)

I cannot use the MSP430 ROM BSL, because the custom board, already in
production, has a connector with the UARTs signals (not the hw BSL
signals), and we cannot make hardware changes (it is a pity we cannot
configure the hw BSL signals).

To run the my BSL I only modify the reset vector, set = 0xF000.
So at reset the MSP430 starts my BSL.
It waits a bit for a firmware upload at the UARTs, at the end it starts
the firmware.

The problem is that my bootload has to work with a firmware, but the
firmware doesn't know it is launched by my bootloader (and not by a
normal cpu reset).

What do you think of this routine ?

void simulate_reset_and_run(void)
// reset the MSP430 to start-up conditions and launch the firmware
{
// reset USARTs
    U0ME &= ~(UTXE0 + URXE0);
    UCTL0 = SWRST;
    U1ME &= ~(UTXE1 + URXE1);
    UCTL1 = SWRST;

// reset modified ports
    P2DIR= 0;
    P3DIR= 0;
    P3SEL= 0;
    P5DIR= 0;

// reset clock to POR/PUC - how to ?

// Init watchdog timer - it is safe ?
    WDTCTL= WDTPW;

// reset interrupts and their flags
    IE1= IE2= 0;
    IFG2= IFG1= 0;

// launch the firmware
    asm jump 0x1100
}



ciao, Massimo

> What do you think of this routine ?
...
>     asm jump 0x1100

If the question is "How does one do a software reset?", a valid answer
would be execute an instruction that results in an NMI.  FCTL1 = 0 will
accomplish that.  Keep in mind it's not a power on reset (POR).  IMO,
it's a slight improvement over "jump 0x1100".  I don't beleive there's
a way to get the device to do a POR from SW.

JJS

massimo.sala@mclink.net wrote:

> I cannot use the MSP430 ROM BSL, because the custom board, already in
> production, has a connector with the UARTs signals (not the hw BSL
> signals), and we cannot make hardware changes (it is a pity we cannot
> configure the hw BSL signals).
> 
> To run the my BSL I only modify the reset vector, set = 0xF000.
> So at reset the MSP430 starts my BSL.
> It waits a bit for a firmware upload at the UARTs, at the end it starts
> the firmware.
> 
> The problem is that my bootload has to work with a firmware, but the
> firmware doesn't know it is launched by my bootloader (and not by a
> normal cpu reset).

If a PUC is sufficient you can easily use the watchdog to do it.
If not look at the user's guide: it gives POR-values for all registers.

/Jan-Hinnerk

johnspeth@yahoo.com wrote:
>> What do you think of this routine ?
> ...
>>     asm jump 0x1100
> 
> If the question is "How does one do a software reset?", a valid answer
> would be execute an instruction that results in an NMI.  FCTL1 = 0 will
> accomplish that.  Keep in mind it's not a power on reset (POR).  IMO,
> it's a slight improvement over "jump 0x1100".  I don't beleive there's
> a way to get the device to do a POR from SW.
> 
> JJS
> 

You can cause a full reset with "WDTCTL = 0", giving the watchdog an 
invalid value.  Whether that helps the O/P or not, I don't know, but it 
is certainly as clear a reset as a POR.