Hello All
I am a newcomer to the MSP430, I would like to implemented a flash 
bootloader on the MSPF1611 using existing on UART to talk to an 
existing PC VB application via the serial link, so this would 
probably involve copying code to RAM and running a small bootloader 
from RAM. Has any one done this? If so is there any VB and/or MSP 
code examples? I have already got a VB application talking to an 
MSPF1232 fine.
Any pointers would be much appreciated.

Jeff Allan

Jeff,

> Hello All
> I am a newcomer to the MSP430, I would like to implemented a flash 
> bootloader on the MSPF1611 using existing on UART to talk to an 
> existing PC VB application via the serial link

It would be nice to know where you got the 1611 from, of course...
What's wrong with the rommed BSL?

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for MSP430 and ARM processors 

Hi,

> What's wrong with the rommed BSL?

The BSL needs extra hardware, you need more than RxD and TxD.

For a Flash boot strap loader you first need a loader which is copied 
into RAM and does the Flash update (with interrupts disabled and 
therefore a software uart) - including updating the Flash boot strap 
loader (in the Flash).

Regards

Rolf F.

> > What's wrong with the rommed BSL?
> 
> The BSL needs extra hardware, you need more than RxD and TxD.
> 
> For a Flash boot strap loader you first need a loader which is copied 
> into RAM and does the Flash update (with interrupts disabled and 
> therefore a software uart) - including updating the Flash boot strap 
> loader (in the Flash).

I don't think you need to run a loader from RAM. If your loader is
sufficiently debugged, it can stay in flash.

-- Paul.

--- In msp430@msp4..., r f <nobodyo@w...> wrote:
> Hi,
> 
> > What's wrong with the rommed BSL?
> 
> The BSL needs extra hardware, you need more than RxD and TxD.
> 
Not necessarily. You can tie the BSL's Rx and Tx to your UART's
Rx 
and Tx lines (unless you don't need them for other functions). Keep 
the BSL pins in input state.
To update, switch the UART's pins to input and then call the rommed 
BSL.
You can invoke the BSL from your application code, so you don't need 
the RST/NIM pins to do that.

Wolfgang

Wolfgang,
 
Did you try/use this? Already?? If so would you happen to have a small
piece of example code so we could try this aswell. Do you use the BSL
program from TI or your own?
 
thanks Martijn.
  _____  

From: Wolfgang Reich [mailto:reich_wolfgang@reic...] 
Sent: dinsdag 18 november 2003 23:29
To: msp430@msp4...
Subject: [msp430] Re: Flash boot strap loader
 
--- In msp430@msp4..., r f <nobodyo@w...> wrote:
> Hi,
> 
> > What's wrong with the rommed BSL?
> 
> The BSL needs extra hardware, you need more than RxD and TxD.
> 
Not necessarily. You can tie the BSL's Rx and Tx to your UART's
Rx 
and Tx lines (unless you don't need them for other functions). Keep 
the BSL pins in input state.
To update, switch the UART's pins to input and then call the rommed 
BSL.
You can invoke the BSL from your application code, so you don't need 
the RST/NIM pins to do that.

Wolfgang





click here
<http://rd.yahoo.com/SIGcp87j50/M&7637.4116719.5338353.1261774/D=eg
roupweb/S05005378:HM/EXP69280942/A53618/R=0/*http:/www.netflix.
com/Default?mqso`178338&partidA16719> 
 
<http://us.adserver.yahoo.com/l?M&7637.4116719.5338353.1261774/D=egrou
pmail/S=:HM/A53618/rand10677120> 

.



">http://docs.yahoo.com/info/terms/> . 

--- In msp430@msp4..., "Wolfgang Reich" 
<reich_wolfgang@y...> wrote:
> --- In msp430@msp4..., r f <nobodyo@w...>
wrote:
> > Hi,
> > 
> > > What's wrong with the rommed BSL?
> > 
> > The BSL needs extra hardware, you need more than RxD and TxD.
> > 
> Not necessarily. You can tie the BSL's Rx and Tx to your UART's
Rx 
> and Tx lines (unless you don't need them for other functions). 
Keep 
> the BSL pins in input state.
> To update, switch the UART's pins to input and then call the 
rommed 
> BSL.
> You can invoke the BSL from your application code, so you don't 
need 
> the RST/NIM pins to do that.

> The only thing that concerns me about the
bootloader being in ram, 
is if there is a problem during/after download, you have no way of 
getting back, other than togling the NMI/RST TEST/TCK pins.

Jeff Allan


> Wolfgang

--- In msp430@msp4..., "Martijn Broens" <martijn@a...>
wrote:
> Wolfgang,
>  
> Did you try/use this? Already??
Yes, on a MSP430F435.

> If so would you happen to have a small
> piece of example code so we could try this aswell.
Here it is:
   WD_vDisable();
   DINT();
   FLL_CTL1 &= ~SMCLKOFF; // BSL seems to need SMCLK, does not work 
if SMCLKOFF is set!
   Lcd_vOff();

   // call BSL
/$
   BR &0c00h;
$/
The inline assembler syntax is for Quadravox AQ430.
The UART port pin switching code is not included here.

See also http://groups.yahoo.com/group/msp430/message/2644
and http://groups.yahoo.com/group/msp430/message/2066

> Do you use the BSL
> program from TI or your own?
TI's BSLDEMO.EXE.

Hope this helps,
Wolfgang

>   _____  
> 
> From: Wolfgang Reich [mailto:reich_wolfgang@y...] 
> Sent: dinsdag 18 november 2003 23:29
> To: msp430@msp4...
> Subject: [msp430] Re: Flash boot strap loader
>  
> --- In msp430@msp4..., r f <nobodyo@w...> wrote:
> > Hi,
> > 
> > > What's wrong with the rommed BSL?
> > 
> > The BSL needs extra hardware, you need more than RxD and TxD.
> > 
> Not necessarily. You can tie the BSL's Rx and Tx to your UART's
Rx 
> and Tx lines (unless you don't need them for other functions). Keep 
> the BSL pins in input state.
> To update, switch the UART's pins to input and then call the rommed 
> BSL.
> You can invoke the BSL from your application code, so you don't 
need 
> the RST/NIM pins to do that.
> 
> Wolfgang
> 
> 
> 
> 
> 
> click here
> 
<http://rd.yahoo.com/SIGcp87j50/M&7637.4116719.5338353.1261774/D=
eg
> 
roupweb/S05005378:HM/EXP69280942/A53618/R=0/*http:/www.netfli
x.
> com/Default?mqso`178338&partidA16719> 
>  
> <http://us.adserver.yahoo.com/l?
M&7637.4116719.5338353.1261774/D=egrou
> pmail/S=:HM/A53618/rand10677120> 
> 
> .
> 
> 
> 
> ">http://docs.yahoo.com/info/terms/> . 
> 
> 
> 

--- In msp430@msp4..., "Jeff" <jeff_allan@y...> wrote:
> --- In msp430@msp4..., "Wolfgang Reich" 
> <reich_wolfgang@y...> wrote:
> > --- In msp430@msp4..., r f <nobodyo@w...> wrote:
> > > Hi,
> > > 
> > > > What's wrong with the rommed BSL?
> > > 
> > > The BSL needs extra hardware, you need more than RxD and TxD.
> > > 
> > Not necessarily. You can tie the BSL's Rx and Tx to your
UART's 
Rx 
> > and Tx lines (unless you don't need them
for other functions). 
> Keep 
> > the BSL pins in input state.
> > To update, switch the UART's pins to input and then call the 
> rommed 
> > BSL.
> > You can invoke the BSL from your application code, so you don't 
> need 
> > the RST/NIM pins to do that.
> 
> > The only thing that concerns me about the bootloader being in 
ram, 
> is if there is a problem during/after download,
you have no way of 
> getting back, other than togling the NMI/RST TEST/TCK pins.
> 
> Jeff Allan

That's the disadvantage of the software-invoked BSL method.


> 
> 
> > Wolfgang

>
>That's the disadvantage of the software-invoked BSL method.
>

I have done this before for a different flash based microprocessor.
Unfortunately, "as always", things are much more complicated than one
can 
think.
I do not use the BSL method for this task, and, yes I use a Ram based 
routine, this for several reasons.
I cannot fully explain everything or give sample code here, simply because 
of time costraints.
It is absolutely right to share as much as possible, I got good hints and I 
like the idea to give (good) hints to other people, but I cannot give much 
more than general hints.
So do not ask for the actual code sample.

In my systems the serial (by now RS232, soon Bluetooth and/or USB) 
connection is supervised by a piece of program that can decode simple 
commands like "print a measurement".
One command is decoded as "start loading code in RAM"
A subsequent command may be "execute the loaded code". Or this can be 
implicit if the previous was successfull.
The loaded program (residing in RAM) will be responsible for load/flash cycle.
It will interface with the serial link and decode, check, load, answer etc 
... to a number of commands, including restart the system.

This architecture gives a number of advantages.
1: I do not keep in the micro RESIDENT code that can flash out the good 
program. The BSL code is there, of course, but I have no code that will 
call it and I do not connect it to the external world anyhow.

2: The loaded code, properly written, can check and exclude certain 
actions, eg. do not accept to re-write certain areas.

3: One such area may be an area reserved for "recovery". Something
that can 
restart the system with minimal functions if it finds that the newly loaded 
program is corrupted, it shall, of course, include the function to re-load 
new code...

4: Once you have it, you can use the same mechanism to load temporary 
programs, with completely different purpose, eg. test/calibration etc.

I agree that coding all that stuff properly is not a little task, but not 
an impossible one, let's say some 200 lines in C. will possibly need 1000 
bytes flash code. Possibly less, depending on how many safety checks you 
feel adequate.

Regards
Antonio