I am interested in making a bootloader for the MSP430FG4618 using IAR
4kb kickstart version.
I have experience making bootloaders for AVR uCs using x-modem and
proprietary protocols, and I would like to do something similar with
this chip and compiler.
The idea is this:
1. the uC starts(inits)
2. delays say 5 seconds
3. if signalled to upgrade within delay period then proceed with
upgrade (UART / data packets) then create checksum and store is
somewhere, run application code
4. if no upgrade, check flash crc or checksum
5. if checksum okay then run application code
My questions are:
1. Can I make my own bootloader for this chip, I have read that there
is already an onboard bootloader (slaa096d.pdf) but can I make my own?
2. Will this compiler allow me to compile a bootloader (1kb I
believe)?
3. If so, where is the bootloader section in flash and how do I tell
IAR to put my code there?
4. How are interrupts shared/divided between the bootloader and
application code?
5. Can I protect the bootloader section from being modified so it is
always present on the chip?
Any help is appreciated. Thanks in advance.
Bootloader
Started by ●October 30, 2007
Reply by ●October 30, 20072007-10-30
--- In m..., "Paul Curtis" wrote:
>
> Hi,
>
> > 1. Can I make my own bootloader for this chip, I have read that
there
> > is already an onboard bootloader (slaa096d.pdf) but can I make my
own?
>
> You can't replace the on-board bootstrap loader (BSL) as it's in
rom.
>
> > 2. Will this compiler allow me to compile a bootloader (1kb I
> > believe)?
>
> 1K yes, but your bootloader needs to go into flash as a regular app
to be
> run after reset.
>
> > 3. If so, where is the bootloader section in flash and how do I
tell
> > IAR to put my code there?
>
> There is nothing like the AVR bootloader scheme on an MSP430.
>
> > 4. How are interrupts shared/divided between the bootloader and
> > application code?
>
> Up to you.
>
> > 5. Can I protect the bootloader section from being modified so it
is
> > always present on the chip?
>
> Blow the fuse, and don't overwrite your bootloader...
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
>
More questions:
1. Is the bootloader's only size restriction the size of the flash?
2. Can the interrupt table be moved? (I'm guessing not)
3. So the key in MSP430 takes the place of the protection bits in AVR
somewhat?
4. From my understanding I should have the reset 0xFFFE point to my
bootloader near the end of flash (unsing no interrupts). When I
upgrade the application code I should upgrade the interrupt table
except the reset vector. The Application code should be placed at the
start of the flash as normal. And I will not use interrupts in my
bootloader. Does this sound like a good way to do it?
5. How do I specify start of code location in IAR?
6. Can I compile to a bin or hex file?
>
> Hi,
>
> > 1. Can I make my own bootloader for this chip, I have read that
there
> > is already an onboard bootloader (slaa096d.pdf) but can I make my
own?
>
> You can't replace the on-board bootstrap loader (BSL) as it's in
rom.
>
> > 2. Will this compiler allow me to compile a bootloader (1kb I
> > believe)?
>
> 1K yes, but your bootloader needs to go into flash as a regular app
to be
> run after reset.
>
> > 3. If so, where is the bootloader section in flash and how do I
tell
> > IAR to put my code there?
>
> There is nothing like the AVR bootloader scheme on an MSP430.
>
> > 4. How are interrupts shared/divided between the bootloader and
> > application code?
>
> Up to you.
>
> > 5. Can I protect the bootloader section from being modified so it
is
> > always present on the chip?
>
> Blow the fuse, and don't overwrite your bootloader...
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
>
More questions:
1. Is the bootloader's only size restriction the size of the flash?
2. Can the interrupt table be moved? (I'm guessing not)
3. So the key in MSP430 takes the place of the protection bits in AVR
somewhat?
4. From my understanding I should have the reset 0xFFFE point to my
bootloader near the end of flash (unsing no interrupts). When I
upgrade the application code I should upgrade the interrupt table
except the reset vector. The Application code should be placed at the
start of the flash as normal. And I will not use interrupts in my
bootloader. Does this sound like a good way to do it?
5. How do I specify start of code location in IAR?
6. Can I compile to a bin or hex file?
Reply by ●October 30, 20072007-10-30
From: m... [mailto:m...] On Behalf
Of mrobins99
Sent: October 30, 2007 12:06 PM
To: m...
Subject: [msp430] Re: Bootloader
More questions:
1. Is the bootloader's only size restriction the size of the flash?
If you roll your own, you can make it as big or small as you want. I'd
suggest keeping it small. Remember to ensure there is enough room for
your bootloader, your application + future feature creep.
2. Can the interrupt table be moved? (I'm guessing not)
Moved - in a round about way. You can redirect the interrupts to a jump
table in your bootloader which can redirect them to your application
IVT. I'd avoid placing the application IVT in the default memory
locations ( FFE0 - FFFF ) because you don't want to have to recompile
your bootloader everytime the application changes( assuming you stick
the bootloader right under the FFE0...)
Use the reset vector to fire up your bootloader. Ours waits for a
password from the serial port for the first second, then runs a crc over
the application code and jumps to the application if the crc verifies.
The rest of the interrupts are redirected via the jump table to the
application IVT. Works great - we use it every day..
3. So the key in MSP430 takes the place of the protection bits in AVR
somewhat?
For the bootloader that is resident in the msp430 flash from the
factory... ( It's been a while since I've done avr stuff ) The msp430
bootloader uses the IVT as the password essentially. Are the protection
bits like a password?
4. From my understanding I should have the reset 0xFFFE point to my
bootloader near the end of flash (unsing no interrupts). When I
upgrade the application code I should upgrade the interrupt table
except the reset vector. The Application code should be placed at the
start of the flash as normal. And I will not use interrupts in my
bootloader. Does this sound like a good way to do it?
See 2. You want to consider decoupling your application IVT from the
default memory locations.
5. How do I specify start of code location in IAR?
Not sure, I use gcc.
6. Can I compile to a bin or hex file?
Yup.
Good luck, it took me a while to sort it all out.
Michael
Of mrobins99
Sent: October 30, 2007 12:06 PM
To: m...
Subject: [msp430] Re: Bootloader
More questions:
1. Is the bootloader's only size restriction the size of the flash?
If you roll your own, you can make it as big or small as you want. I'd
suggest keeping it small. Remember to ensure there is enough room for
your bootloader, your application + future feature creep.
2. Can the interrupt table be moved? (I'm guessing not)
Moved - in a round about way. You can redirect the interrupts to a jump
table in your bootloader which can redirect them to your application
IVT. I'd avoid placing the application IVT in the default memory
locations ( FFE0 - FFFF ) because you don't want to have to recompile
your bootloader everytime the application changes( assuming you stick
the bootloader right under the FFE0...)
Use the reset vector to fire up your bootloader. Ours waits for a
password from the serial port for the first second, then runs a crc over
the application code and jumps to the application if the crc verifies.
The rest of the interrupts are redirected via the jump table to the
application IVT. Works great - we use it every day..
3. So the key in MSP430 takes the place of the protection bits in AVR
somewhat?
For the bootloader that is resident in the msp430 flash from the
factory... ( It's been a while since I've done avr stuff ) The msp430
bootloader uses the IVT as the password essentially. Are the protection
bits like a password?
4. From my understanding I should have the reset 0xFFFE point to my
bootloader near the end of flash (unsing no interrupts). When I
upgrade the application code I should upgrade the interrupt table
except the reset vector. The Application code should be placed at the
start of the flash as normal. And I will not use interrupts in my
bootloader. Does this sound like a good way to do it?
See 2. You want to consider decoupling your application IVT from the
default memory locations.
5. How do I specify start of code location in IAR?
Not sure, I use gcc.
6. Can I compile to a bin or hex file?
Yup.
Good luck, it took me a while to sort it all out.
Michael
Reply by ●October 31, 20072007-10-31
mrobins99 wrote:
> 5. How do I specify start of code location in IAR?
You have to tell the linker to do it in the linker command file (with
extension .xcl).
By default, functions are placed in the segment "CODE", you can place it
anywhere you like.
Alternatively, you can use the '@ "MY_CODE"' syntax to place individual
functions in specific segments. In that case you have to add the
corresponding segments to your linker command file.
-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.
> 5. How do I specify start of code location in IAR?
You have to tell the linker to do it in the linker command file (with
extension .xcl).
By default, functions are placed in the segment "CODE", you can place it
anywhere you like.
Alternatively, you can use the '@ "MY_CODE"' syntax to place individual
functions in specific segments. In that case you have to add the
corresponding segments to your linker command file.
-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.
Reply by ●October 31, 20072007-10-31
--- In m..., Anders Lindgren
wrote:
>
> mrobins99 wrote:
>
> > 5. How do I specify start of code location in IAR?
>
> You have to tell the linker to do it in the linker command file
(with
> extension .xcl).
>
> By default, functions are placed in the segment "CODE", you can
place it
> anywhere you like.
>
> Alternatively, you can use the '@ "MY_CODE"' syntax to place
individual
> functions in specific segments. In that case you have to add the
> corresponding segments to your linker command file.
>
> -- Anders Lindgren, IAR Systems
> --
> Disclaimer: Opinions expressed in this posting are strictly my own
and
> not necessarily those of my employer.
>
These answers are helping me understand things more, and giving me
more questions.
The chip I am using is the MSP430FG4618(cannot use gcc not
compatible), so the memory is split up somewhat I think, with the IVT
in the middle. This looks as though it may complicate things a
little. I was hoping to compile to a bin file so that I could write
the application code to consecutive memory locations.
1. When I do my vector table for my bootloader, as I understand it I
should provide each interrupt function in the code and have each jump
to a location where I choose to have the application interrupt vector
table, this in turn will jump to the interrupt in the application
code so I am effectively redirrecting all the interrupts except the
reset. Is this right?
Like this:
Bootloader IVT --> Bootloader ISR --> Application IVT --> Application
ISR
Or perhaps like this (but how???):
Bootloader IVT --> Application IVT --> Application ISR
2. How do I get IAR to output a bin or hex file?
3. I found the .xcl file to change locations of different code
spaces, so now I have to make one for my bootloader and another for
every application code that I write based on where my bootloader puts
the code. Is this correct?
Thanks for your help, hopefully this thread assists others in their
bootloader efforts as well.
wrote:
>
> mrobins99 wrote:
>
> > 5. How do I specify start of code location in IAR?
>
> You have to tell the linker to do it in the linker command file
(with
> extension .xcl).
>
> By default, functions are placed in the segment "CODE", you can
place it
> anywhere you like.
>
> Alternatively, you can use the '@ "MY_CODE"' syntax to place
individual
> functions in specific segments. In that case you have to add the
> corresponding segments to your linker command file.
>
> -- Anders Lindgren, IAR Systems
> --
> Disclaimer: Opinions expressed in this posting are strictly my own
and
> not necessarily those of my employer.
>
These answers are helping me understand things more, and giving me
more questions.
The chip I am using is the MSP430FG4618(cannot use gcc not
compatible), so the memory is split up somewhat I think, with the IVT
in the middle. This looks as though it may complicate things a
little. I was hoping to compile to a bin file so that I could write
the application code to consecutive memory locations.
1. When I do my vector table for my bootloader, as I understand it I
should provide each interrupt function in the code and have each jump
to a location where I choose to have the application interrupt vector
table, this in turn will jump to the interrupt in the application
code so I am effectively redirrecting all the interrupts except the
reset. Is this right?
Like this:
Bootloader IVT --> Bootloader ISR --> Application IVT --> Application
ISR
Or perhaps like this (but how???):
Bootloader IVT --> Application IVT --> Application ISR
2. How do I get IAR to output a bin or hex file?
3. I found the .xcl file to change locations of different code
spaces, so now I have to make one for my bootloader and another for
every application code that I write based on where my bootloader puts
the code. Is this correct?
Thanks for your help, hopefully this thread assists others in their
bootloader efforts as well.
Reply by ●October 31, 20072007-10-31
Hi mrobins99!
> These answers are helping me understand things more, and giving me
> more questions.
>
> The chip I am using is the MSP430FG4618(cannot use gcc not
> compatible), so the memory is split up somewhat I think, with the IVT
> in the middle. This looks as though it may complicate things a
> little. I was hoping to compile to a bin file so that I could write
> the application code to consecutive memory locations.
>
> 1. When I do my vector table for my bootloader, as I understand it I
> should provide each interrupt function in the code and have each jump
> to a location where I choose to have the application interrupt vector
> table, this in turn will jump to the interrupt in the application
> code so I am effectively redirrecting all the interrupts except the
> reset. Is this right?
>
> Like this:
> Bootloader IVT --> Bootloader ISR --> Application IVT --> Application
> ISR
>
> Or perhaps like this (but how???):
> Bootloader IVT --> Application IVT --> Application ISR
You can't get an IVT to jump to an IVT, since an IVT only contains
addresses.
You could set up the real IVT so that it jumps into a table with real
branch instructions, that are specific to the application in question.
This jump table must be in the lower 64KB of memory, but the branches
will be able to call the upper parts, effectively eliminating the high
vs. low memory problem.
> 2. How do I get IAR to output a bin or hex file?
The linker is capable of generating a zillion different output formats,
most of which I've never even heard of. Take a look in the section
"XLINK Output Formats" in the XLink manual (available as a pdf in the
"help" menu).
> 3. I found the .xcl file to change locations of different code
> spaces, so now I have to make one for my bootloader and another for
> every application code that I write based on where my bootloader puts
> the code. Is this correct?
Bootloaders has been discussed here earlier. It seems like people have
concluded that it's easier to create separate projects for the
bootloader itself, and for the applications, just like you suggested.
You will probably need dedicated .xcl files.
> Thanks for your help, hopefully this thread assists others in their
> bootloader efforts as well.
You're welcome!
-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.
> These answers are helping me understand things more, and giving me
> more questions.
>
> The chip I am using is the MSP430FG4618(cannot use gcc not
> compatible), so the memory is split up somewhat I think, with the IVT
> in the middle. This looks as though it may complicate things a
> little. I was hoping to compile to a bin file so that I could write
> the application code to consecutive memory locations.
>
> 1. When I do my vector table for my bootloader, as I understand it I
> should provide each interrupt function in the code and have each jump
> to a location where I choose to have the application interrupt vector
> table, this in turn will jump to the interrupt in the application
> code so I am effectively redirrecting all the interrupts except the
> reset. Is this right?
>
> Like this:
> Bootloader IVT --> Bootloader ISR --> Application IVT --> Application
> ISR
>
> Or perhaps like this (but how???):
> Bootloader IVT --> Application IVT --> Application ISR
You can't get an IVT to jump to an IVT, since an IVT only contains
addresses.
You could set up the real IVT so that it jumps into a table with real
branch instructions, that are specific to the application in question.
This jump table must be in the lower 64KB of memory, but the branches
will be able to call the upper parts, effectively eliminating the high
vs. low memory problem.
> 2. How do I get IAR to output a bin or hex file?
The linker is capable of generating a zillion different output formats,
most of which I've never even heard of. Take a look in the section
"XLINK Output Formats" in the XLink manual (available as a pdf in the
"help" menu).
> 3. I found the .xcl file to change locations of different code
> spaces, so now I have to make one for my bootloader and another for
> every application code that I write based on where my bootloader puts
> the code. Is this correct?
Bootloaders has been discussed here earlier. It seems like people have
concluded that it's easier to create separate projects for the
bootloader itself, and for the applications, just like you suggested.
You will probably need dedicated .xcl files.
> Thanks for your help, hopefully this thread assists others in their
> bootloader efforts as well.
You're welcome!
-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.
Reply by ●October 31, 20072007-10-31
--- In m..., "mrobins99" wrote:
> The chip I am using is the MSP430FG4618(cannot use gcc not
> compatible)
I don't think that's true. I know that it is compatible at least with
the basic non-extended addressing. And I see that some people have
been adding the extended (over 64K) addressing support to mspgcc, but
I don't know how stable it is yet.
Certainly 64K is a lot bigger than the 4K you get for free from IAR.
By the way, just to be fair, the 4K limitation is only on C code.
There is no limit on assembly code. Many people write bootloaders in
assembly language just to keep the size down as small as possible, but
you can also use C.
Eric
> The chip I am using is the MSP430FG4618(cannot use gcc not
> compatible)
I don't think that's true. I know that it is compatible at least with
the basic non-extended addressing. And I see that some people have
been adding the extended (over 64K) addressing support to mspgcc, but
I don't know how stable it is yet.
Certainly 64K is a lot bigger than the 4K you get for free from IAR.
By the way, just to be fair, the 4K limitation is only on C code.
There is no limit on assembly code. Many people write bootloaders in
assembly language just to keep the size down as small as possible, but
you can also use C.
Eric
Reply by ●October 31, 20072007-10-31
Hi,
You want to go like this:
Default IVT --> Bootloader Jump Table --> Application IVT -->
Application
ISR
The Default IVT contains the addresses of the instructions to be
executed, if you put the address of your application IVT in there, the
table contains the address of an address and the processor won't have
much success executing that instruction! You need to use the jump table
as a middleman and branch to the application's IVT.
Hook into the reset vector for your bootloader, don't use interrupts for
your serial routines in the bootloader and you should be good to go.
Once again - good luck,
Michael
________________________________
From: m... [mailto:m...] On Behalf
Of mrobins99
Sent: October 31, 2007 06:25 AM
To: m...
Subject: [msp430] Re: Bootloader
These answers are helping me understand things more, and giving me
more questions.
The chip I am using is the MSP430FG4618(cannot use gcc not
compatible), so the memory is split up somewhat I think, with the IVT
in the middle. This looks as though it may complicate things a
little. I was hoping to compile to a bin file so that I could write
the application code to consecutive memory locations.
1. When I do my vector table for my bootloader, as I understand it I
should provide each interrupt function in the code and have each jump
to a location where I choose to have the application interrupt vector
table, this in turn will jump to the interrupt in the application
code so I am effectively redirrecting all the interrupts except the
reset. Is this right?
2. How do I get IAR to output a bin or hex file?
3. I found the .xcl file to change locations of different code
spaces, so now I have to make one for my bootloader and another for
every application code that I write based on where my bootloader puts
the code. Is this correct?
Thanks for your help, hopefully this thread assists others in their
bootloader efforts as well.
You want to go like this:
Default IVT --> Bootloader Jump Table --> Application IVT -->
Application
ISR
The Default IVT contains the addresses of the instructions to be
executed, if you put the address of your application IVT in there, the
table contains the address of an address and the processor won't have
much success executing that instruction! You need to use the jump table
as a middleman and branch to the application's IVT.
Hook into the reset vector for your bootloader, don't use interrupts for
your serial routines in the bootloader and you should be good to go.
Once again - good luck,
Michael
________________________________
From: m... [mailto:m...] On Behalf
Of mrobins99
Sent: October 31, 2007 06:25 AM
To: m...
Subject: [msp430] Re: Bootloader
These answers are helping me understand things more, and giving me
more questions.
The chip I am using is the MSP430FG4618(cannot use gcc not
compatible), so the memory is split up somewhat I think, with the IVT
in the middle. This looks as though it may complicate things a
little. I was hoping to compile to a bin file so that I could write
the application code to consecutive memory locations.
1. When I do my vector table for my bootloader, as I understand it I
should provide each interrupt function in the code and have each jump
to a location where I choose to have the application interrupt vector
table, this in turn will jump to the interrupt in the application
code so I am effectively redirrecting all the interrupts except the
reset. Is this right?
2. How do I get IAR to output a bin or hex file?
3. I found the .xcl file to change locations of different code
spaces, so now I have to make one for my bootloader and another for
every application code that I write based on where my bootloader puts
the code. Is this correct?
Thanks for your help, hopefully this thread assists others in their
bootloader efforts as well.
Reply by ●October 31, 20072007-10-31
--- In m..., "Michael Iverson" wrote:
>
> Hi,
>
> You want to go like this:
>
> Default IVT --> Bootloader Jump Table --> Application IVT -->
> Application
> ISR
>
> The Default IVT contains the addresses of the instructions to be
> executed, if you put the address of your application IVT in there,
the
> table contains the address of an address and the processor won't
have
> much success executing that instruction! You need to use the jump
table
> as a middleman and branch to the application's IVT.
>
> Hook into the reset vector for your bootloader, don't use
interrupts for
> your serial routines in the bootloader and you should be good to go.
>
> Once again - good luck,
>
> Michael
> ________________________________
>
> From: m... [mailto:m...] On
Behalf
> Of mrobins99
> Sent: October 31, 2007 06:25 AM
> To: m...
> Subject: [msp430] Re: Bootloader
>
> These answers are helping me understand things more, and giving me
> more questions.
>
> The chip I am using is the MSP430FG4618(cannot use gcc not
> compatible), so the memory is split up somewhat I think, with the
IVT
> in the middle. This looks as though it may complicate things a
> little. I was hoping to compile to a bin file so that I could write
> the application code to consecutive memory locations.
>
> 1. When I do my vector table for my bootloader, as I understand it
I
> should provide each interrupt function in the code and have each
jump
> to a location where I choose to have the application interrupt
vector
> table, this in turn will jump to the interrupt in the application
> code so I am effectively redirrecting all the interrupts except the
> reset. Is this right?
>
> 2. How do I get IAR to output a bin or hex file?
>
> 3. I found the .xcl file to change locations of different code
> spaces, so now I have to make one for my bootloader and another for
> every application code that I write based on where my bootloader
puts
> the code. Is this correct?
>
> Thanks for your help, hopefully this thread assists others in their
> bootloader efforts as well.
>
Yes I have figured it out.
application code --> 0x10000 - 0x1FFFF
bootloader reset address--> 0x0FFFE - 0xFFFF (probably 0x03100)
application IVT --> 0x0FFC0 - 0x0FFFD
application code --> 0x06004 - 0x0FFBF
application reset address--> 0x06002 - 0x06003 (maybe 0x06004)
application crc --> 0x06000 - 0x06001
bootloader code --> 0x03100 - 0x05FFF
Using the JTAG connector I will program the bootloader portions.
Using the serial port I will program the application portions but
will put the data for 0x0FFFE - 0xFFFF in 0x06002 - 0x06003 instead,
so I know where to branch to run the application from within the
bootloader. I will also calculate a 16 bit crc afterwards from
0x06002 - 0x1FFFF and store it at 0x06000 - 0x06001 for flash
verification.
Any comments or suggections on my approach?
>
> Hi,
>
> You want to go like this:
>
> Default IVT --> Bootloader Jump Table --> Application IVT -->
> Application
> ISR
>
> The Default IVT contains the addresses of the instructions to be
> executed, if you put the address of your application IVT in there,
the
> table contains the address of an address and the processor won't
have
> much success executing that instruction! You need to use the jump
table
> as a middleman and branch to the application's IVT.
>
> Hook into the reset vector for your bootloader, don't use
interrupts for
> your serial routines in the bootloader and you should be good to go.
>
> Once again - good luck,
>
> Michael
> ________________________________
>
> From: m... [mailto:m...] On
Behalf
> Of mrobins99
> Sent: October 31, 2007 06:25 AM
> To: m...
> Subject: [msp430] Re: Bootloader
>
> These answers are helping me understand things more, and giving me
> more questions.
>
> The chip I am using is the MSP430FG4618(cannot use gcc not
> compatible), so the memory is split up somewhat I think, with the
IVT
> in the middle. This looks as though it may complicate things a
> little. I was hoping to compile to a bin file so that I could write
> the application code to consecutive memory locations.
>
> 1. When I do my vector table for my bootloader, as I understand it
I
> should provide each interrupt function in the code and have each
jump
> to a location where I choose to have the application interrupt
vector
> table, this in turn will jump to the interrupt in the application
> code so I am effectively redirrecting all the interrupts except the
> reset. Is this right?
>
> 2. How do I get IAR to output a bin or hex file?
>
> 3. I found the .xcl file to change locations of different code
> spaces, so now I have to make one for my bootloader and another for
> every application code that I write based on where my bootloader
puts
> the code. Is this correct?
>
> Thanks for your help, hopefully this thread assists others in their
> bootloader efforts as well.
>
Yes I have figured it out.
application code --> 0x10000 - 0x1FFFF
bootloader reset address--> 0x0FFFE - 0xFFFF (probably 0x03100)
application IVT --> 0x0FFC0 - 0x0FFFD
application code --> 0x06004 - 0x0FFBF
application reset address--> 0x06002 - 0x06003 (maybe 0x06004)
application crc --> 0x06000 - 0x06001
bootloader code --> 0x03100 - 0x05FFF
Using the JTAG connector I will program the bootloader portions.
Using the serial port I will program the application portions but
will put the data for 0x0FFFE - 0xFFFF in 0x06002 - 0x06003 instead,
so I know where to branch to run the application from within the
bootloader. I will also calculate a 16 bit crc afterwards from
0x06002 - 0x1FFFF and store it at 0x06000 - 0x06001 for flash
verification.
Any comments or suggections on my approach?
Reply by ●October 31, 20072007-10-31
I have a very different approch.
I would use the BSL-ROM to load a second loader into RAM, then start
to execute this second loader to load the application into Flash.
The second loader could use the serial I/O routine inside the BSL-
ROM.
If you like, we can discuss this approch in more detial.
--- In m..., "mrobins99" wrote:
>
> --- In m..., "Michael Iverson" wrote:
> >
> > Hi,
> >
> > You want to go like this:
> >
> > Default IVT --> Bootloader Jump Table --> Application IVT -->
> > Application
> > ISR
> >
> > The Default IVT contains the addresses of the instructions to be
> > executed, if you put the address of your application IVT in
there,
> the
> > table contains the address of an address and the processor won't
> have
> > much success executing that instruction! You need to use the
jump
> table
> > as a middleman and branch to the application's IVT.
> >
> > Hook into the reset vector for your bootloader, don't use
> interrupts for
> > your serial routines in the bootloader and you should be good to
go.
> >
> > Once again - good luck,
> >
> > Michael
> >
> >
> > ________________________________
> >
> > From: m... [mailto:m...] On
> Behalf
> > Of mrobins99
> > Sent: October 31, 2007 06:25 AM
> > To: m...
> > Subject: [msp430] Re: Bootloader
> >
> > These answers are helping me understand things more, and giving
me
> > more questions.
> >
> > The chip I am using is the MSP430FG4618(cannot use gcc not
> > compatible), so the memory is split up somewhat I think, with
the
> IVT
> > in the middle. This looks as though it may complicate things a
> > little. I was hoping to compile to a bin file so that I could
write
> > the application code to consecutive memory locations.
> >
> > 1. When I do my vector table for my bootloader, as I understand
it
> I
> > should provide each interrupt function in the code and have each
> jump
> > to a location where I choose to have the application interrupt
> vector
> > table, this in turn will jump to the interrupt in the
application
> > code so I am effectively redirrecting all the interrupts except
the
> > reset. Is this right?
> >
> >
> >
> > 2. How do I get IAR to output a bin or hex file?
> >
> > 3. I found the .xcl file to change locations of different code
> > spaces, so now I have to make one for my bootloader and another
for
> > every application code that I write based on where my bootloader
> puts
> > the code. Is this correct?
> >
> > Thanks for your help, hopefully this thread assists others in
their
> > bootloader efforts as well.
> > Yes I have figured it out.
>
> application code --> 0x10000 - 0x1FFFF
> bootloader reset address--> 0x0FFFE - 0xFFFF (probably 0x03100)
> application IVT --> 0x0FFC0 - 0x0FFFD
> application code --> 0x06004 - 0x0FFBF
> application reset address--> 0x06002 - 0x06003 (maybe 0x06004)
> application crc --> 0x06000 - 0x06001
> bootloader code --> 0x03100 - 0x05FFF
>
> Using the JTAG connector I will program the bootloader portions.
> Using the serial port I will program the application portions but
> will put the data for 0x0FFFE - 0xFFFF in 0x06002 - 0x06003
instead,
> so I know where to branch to run the application from within the
> bootloader. I will also calculate a 16 bit crc afterwards from
> 0x06002 - 0x1FFFF and store it at 0x06000 - 0x06001 for flash
> verification.
>
> Any comments or suggections on my approach?
>
I would use the BSL-ROM to load a second loader into RAM, then start
to execute this second loader to load the application into Flash.
The second loader could use the serial I/O routine inside the BSL-
ROM.
If you like, we can discuss this approch in more detial.
--- In m..., "mrobins99" wrote:
>
> --- In m..., "Michael Iverson" wrote:
> >
> > Hi,
> >
> > You want to go like this:
> >
> > Default IVT --> Bootloader Jump Table --> Application IVT -->
> > Application
> > ISR
> >
> > The Default IVT contains the addresses of the instructions to be
> > executed, if you put the address of your application IVT in
there,
> the
> > table contains the address of an address and the processor won't
> have
> > much success executing that instruction! You need to use the
jump
> table
> > as a middleman and branch to the application's IVT.
> >
> > Hook into the reset vector for your bootloader, don't use
> interrupts for
> > your serial routines in the bootloader and you should be good to
go.
> >
> > Once again - good luck,
> >
> > Michael
> >
> >
> > ________________________________
> >
> > From: m... [mailto:m...] On
> Behalf
> > Of mrobins99
> > Sent: October 31, 2007 06:25 AM
> > To: m...
> > Subject: [msp430] Re: Bootloader
> >
> > These answers are helping me understand things more, and giving
me
> > more questions.
> >
> > The chip I am using is the MSP430FG4618(cannot use gcc not
> > compatible), so the memory is split up somewhat I think, with
the
> IVT
> > in the middle. This looks as though it may complicate things a
> > little. I was hoping to compile to a bin file so that I could
write
> > the application code to consecutive memory locations.
> >
> > 1. When I do my vector table for my bootloader, as I understand
it
> I
> > should provide each interrupt function in the code and have each
> jump
> > to a location where I choose to have the application interrupt
> vector
> > table, this in turn will jump to the interrupt in the
application
> > code so I am effectively redirrecting all the interrupts except
the
> > reset. Is this right?
> >
> >
> >
> > 2. How do I get IAR to output a bin or hex file?
> >
> > 3. I found the .xcl file to change locations of different code
> > spaces, so now I have to make one for my bootloader and another
for
> > every application code that I write based on where my bootloader
> puts
> > the code. Is this correct?
> >
> > Thanks for your help, hopefully this thread assists others in
their
> > bootloader efforts as well.
> > Yes I have figured it out.
>
> application code --> 0x10000 - 0x1FFFF
> bootloader reset address--> 0x0FFFE - 0xFFFF (probably 0x03100)
> application IVT --> 0x0FFC0 - 0x0FFFD
> application code --> 0x06004 - 0x0FFBF
> application reset address--> 0x06002 - 0x06003 (maybe 0x06004)
> application crc --> 0x06000 - 0x06001
> bootloader code --> 0x03100 - 0x05FFF
>
> Using the JTAG connector I will program the bootloader portions.
> Using the serial port I will program the application portions but
> will put the data for 0x0FFFE - 0xFFFF in 0x06002 - 0x06003
instead,
> so I know where to branch to run the application from within the
> bootloader. I will also calculate a 16 bit crc afterwards from
> 0x06002 - 0x1FFFF and store it at 0x06000 - 0x06001 for flash
> verification.
>
> Any comments or suggections on my approach?
>
