Quantcast

Can the RESET_VECTOR be redefined at compile time to a specific value?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Can the RESET_VECTOR be redefined at compile time to a specific value?

Tomek Lorek
Hi,
My use case is the following: I have a bootloader (up to 4K in size,
residing at 0x4400 to 0x5400) that has a main() function and
application (starting from 0x4800) – they are organized as 2 separate
projects (I want the bootloader to be flashed only once and not
changed later).

I am using mspgcc.

Bootloader and application linker scripts are defined so that their
.text sections (that go to “rom” memory region) are separated but they
use the same “vector” memory region for .vector section (although the
bootloader does not use any interrupts other than reset):

bootloader’s linker script excerpt:
MEMORY {
  …
  rom (rx)         : ORIGIN = 0x4400, LENGTH = 0x1000 /* END=0x5400,
size 4K - bootloader code */
  rom_app (rx)     : ORIGIN = 0x5400, LENGTH = 0xab80 /* END=0xff80,
size 43904 - the field-updatable application */
  vectors          : ORIGIN = 0xff80, LENGTH = 0x0080 /* END=0x10000,
size 128 as 64 2-byte segments */
  …
}

and the application’s linker script excerpt:

MEMORY {
  …
  rom (rx)         : ORIGIN = 0x5400, LENGTH = 0xab80 /* END=0xff80,
size 43904 */
  vectors          : ORIGIN = 0xff80, LENGTH = 0x0080 /* END=0x10000,
size 128 as 64 2-byte segments */
  …
}

I need the bootloader’s init code and main() function be executed upon
power up of the microcontroller. And this would be the case if I only
flash the bootloader’s .elf onto the flash (0xFFFE pointing to
bootloader’s main() function).

But when I then program the application’s image onto the flash the
0xFFFE will point to the application’s reset vector which is not a
bootloader anymore. I'd like to configure my application so that it
always fills 0xFFFE with a fixed address (0x4400).

The rest of the story is that when bootloader is started then of
course the bootloader needs to jump to and execute the application’s
entry point (0x5400) including the app's watchdog preparation, stack
init etc.

Is that doable? How can I define in the application’s code that the
reset vector (0xFFFE) shall contain the bootloader’s init code
(0x4400)?

Best Regards,
Tomek

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Can the RESET_VECTOR be redefined at compile time to a specific value?

Peter Bigot-4
 For what you're doing, you'll want to become familiar with the crt0.S
script from the libgcc/config/msp430 directory of the mspgcc gcc
source.  For simple things you won't need a custom linker script; for
complex things, make sure your modified version doesn't deviate too
far from the standard ones.

Yes, if you define a naked function named _reset_vector__ that's in
section .init0 the mspgcc linker scripts will use it instead of the
default one.

You'd want to do something like:

__attribute__((__naked__,__section__(".init0")))
void _reset_vector (void)
{
   /* stuff goes here */
}

Peter

On Fri, Apr 18, 2014 at 12:08 PM, Tomek Lorek <[hidden email]> wrote:

> Hi,
> My use case is the following: I have a bootloader (up to 4K in size,
> residing at 0x4400 to 0x5400) that has a main() function and
> application (starting from 0x4800) – they are organized as 2 separate
> projects (I want the bootloader to be flashed only once and not
> changed later).
>
> I am using mspgcc.
>
> Bootloader and application linker scripts are defined so that their
> .text sections (that go to “rom” memory region) are separated but they
> use the same “vector” memory region for .vector section (although the
> bootloader does not use any interrupts other than reset):
>
> bootloader’s linker script excerpt:
> MEMORY {
>   …
>   rom (rx)         : ORIGIN = 0x4400, LENGTH = 0x1000 /* END=0x5400,
> size 4K - bootloader code */
>   rom_app (rx)     : ORIGIN = 0x5400, LENGTH = 0xab80 /* END=0xff80,
> size 43904 - the field-updatable application */
>   vectors          : ORIGIN = 0xff80, LENGTH = 0x0080 /* END=0x10000,
> size 128 as 64 2-byte segments */
>   …
> }
>
> and the application’s linker script excerpt:
>
> MEMORY {
>   …
>   rom (rx)         : ORIGIN = 0x5400, LENGTH = 0xab80 /* END=0xff80,
> size 43904 */
>   vectors          : ORIGIN = 0xff80, LENGTH = 0x0080 /* END=0x10000,
> size 128 as 64 2-byte segments */
>   …
> }
>
> I need the bootloader’s init code and main() function be executed upon
> power up of the microcontroller. And this would be the case if I only
> flash the bootloader’s .elf onto the flash (0xFFFE pointing to
> bootloader’s main() function).
>
> But when I then program the application’s image onto the flash the
> 0xFFFE will point to the application’s reset vector which is not a
> bootloader anymore. I'd like to configure my application so that it
> always fills 0xFFFE with a fixed address (0x4400).
>
> The rest of the story is that when bootloader is started then of
> course the bootloader needs to jump to and execute the application’s
> entry point (0x5400) including the app's watchdog preparation, stack
> init etc.
>
> Is that doable? How can I define in the application’s code that the
> reset vector (0xFFFE) shall contain the bootloader’s init code
> (0x4400)?
>
> Best Regards,
> Tomek
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Mspgcc-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Can the RESET_VECTOR be redefined at compile time to a specific value?

Tomek Lorek
2014-04-18 19:40 GMT+02:00 Peter Bigot <[hidden email]>:
Thanks Peter!

> Yes, if you define a naked function named _reset_vector__ that's in
> section .init0 the mspgcc linker scripts will use it instead of the
> default one.
>
> You'd want to do something like:
>
> __attribute__((__naked__,__section__(".init0")))
> void _reset_vector (void)
> {
>    /* stuff goes here */
> }

I;m not sure If I understand your hint correctly - the method above
gives me the possibility of redefining the _reset_vector function
body, but not the address.

I will try to rework the linker script or my application to something like this:

MEMORY
{
...
init0: ORIGIN = 0x4400, LENGTH = 0x2
...

}

SECTIONS
{
  .init0
  {
    *(.init0)
  } > init0
}

and see if that works.

Best Regards,
Tomek

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Can the RESET_VECTOR be redefined at compile time to a specific value?

Wylder Keane-2
Another issue you'll probably run into is if you share any other interrupt
handlers with your bootloader they'll be overwritten when you load your new
software. This is not really avoidable unless you create your own interrupt
table which decides whether to use the bootloader vectors or reset vectors,
but then that code will need to be shared between your bootloader and all
software projects.

Another way is if you only need to share the reset vector then have your
bootloader load the software and redirect only the reset address data
(aimed for 0xFFFE) into a virtual reset point that it can use when your
chip is configured to boot into software. This way when your chip starts up
your bootloader will decide whether to load into software or itself and if
software it'll just branch to the reset address you redirected. You can
then just load your debug symbols as per normal in your debugger and step
through your code. The other added benefit of this is you don't have to
worry about where the reset vector will be pointing for any software that
you load.

I would also suggest putting some MPU protection on your bootloader so your
software doesn't corrupt it.

This will NOT prevent you from overwriting the RESET vector with another
load/prog command, to do that you'd have to enable MPU protection of the
vector table as well and specially unlock it when you enter the bootloader.
You can't just protected the RESET vector as the MPU border registers make
it.so the minimum segment size is 1k.

Hope this helps!


On Fri, Apr 18, 2014 at 11:34 AM, Tomek Lorek <[hidden email]> wrote:

> 2014-04-18 19:40 GMT+02:00 Peter Bigot <[hidden email]>:
> Thanks Peter!
>
> > Yes, if you define a naked function named _reset_vector__ that's in
> > section .init0 the mspgcc linker scripts will use it instead of the
> > default one.
> >
> > You'd want to do something like:
> >
> > __attribute__((__naked__,__section__(".init0")))
> > void _reset_vector (void)
> > {
> >    /* stuff goes here */
> > }
>
> I;m not sure If I understand your hint correctly - the method above
> gives me the possibility of redefining the _reset_vector function
> body, but not the address.
>
> I will try to rework the linker script or my application to something like
> this:
>
> MEMORY
> {
> ...
> init0: ORIGIN = 0x4400, LENGTH = 0x2
> ...
>
> }
>
> SECTIONS
> {
>   .init0
>   {
>     *(.init0)
>   } > init0
> }
>
> and see if that works.
>
> Best Regards,
> Tomek
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Mspgcc-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Can the RESET_VECTOR be redefined at compile time to a specific value?

Tomek Lorek
I think I better use the alternative (RAM resident) vector table for
application, this way the bootloader will not be affected.
18 kwi 2014 21:07 "Wylder Keane" <[hidden email]> napisał(a):

> Another issue you'll probably run into is if you share any other interrupt
> handlers with your bootloader they'll be overwritten when you load your new
> software. This is not really avoidable unless you create your own interrupt
> table which decides whether to use the bootloader vectors or reset vectors,
> but then that code will need to be shared between your bootloader and all
> software projects.
>
> Another way is if you only need to share the reset vector then have your
> bootloader load the software and redirect only the reset address data
> (aimed for 0xFFFE) into a virtual reset point that it can use when your
> chip is configured to boot into software. This way when your chip starts up
> your bootloader will decide whether to load into software or itself and if
> software it'll just branch to the reset address you redirected. You can
> then just load your debug symbols as per normal in your debugger and step
> through your code. The other added benefit of this is you don't have to
> worry about where the reset vector will be pointing for any software that
> you load.
>
> I would also suggest putting some MPU protection on your bootloader so
> your software doesn't corrupt it.
>
> This will NOT prevent you from overwriting the RESET vector with another
> load/prog command, to do that you'd have to enable MPU protection of the
> vector table as well and specially unlock it when you enter the bootloader.
> You can't just protected the RESET vector as the MPU border registers make
> it.so the minimum segment size is 1k.
>
> Hope this helps!
>
>
> On Fri, Apr 18, 2014 at 11:34 AM, Tomek Lorek <[hidden email]> wrote:
>
>> 2014-04-18 19:40 GMT+02:00 Peter Bigot <[hidden email]>:
>> Thanks Peter!
>>
>> > Yes, if you define a naked function named _reset_vector__ that's in
>> > section .init0 the mspgcc linker scripts will use it instead of the
>> > default one.
>> >
>> > You'd want to do something like:
>> >
>> > __attribute__((__naked__,__section__(".init0")))
>> > void _reset_vector (void)
>> > {
>> >    /* stuff goes here */
>> > }
>>
>> I;m not sure If I understand your hint correctly - the method above
>> gives me the possibility of redefining the _reset_vector function
>> body, but not the address.
>>
>> I will try to rework the linker script or my application to something
>> like this:
>>
>> MEMORY
>> {
>> ...
>> init0: ORIGIN = 0x4400, LENGTH = 0x2
>> ...
>>
>> }
>>
>> SECTIONS
>> {
>>   .init0
>>   {
>>     *(.init0)
>>   } > init0
>> }
>>
>> and see if that works.
>>
>> Best Regards,
>> Tomek
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Mspgcc-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>>
>
>

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Can the RESET_VECTOR be redefined at compile time to a specific value?

Peter Bigot-4
In reply to this post by Tomek Lorek
On Fri, Apr 18, 2014 at 1:34 PM, Tomek Lorek <[hidden email]> wrote:

> 2014-04-18 19:40 GMT+02:00 Peter Bigot <[hidden email]>:
> Thanks Peter!
>
>> Yes, if you define a naked function named _reset_vector__ that's in
>> section .init0 the mspgcc linker scripts will use it instead of the
>> default one.
>>
>> You'd want to do something like:
>>
>> __attribute__((__naked__,__section__(".init0")))
>> void _reset_vector (void)
>> {
>>    /* stuff goes here */
>> }
>
> I;m not sure If I understand your hint correctly - the method above
> gives me the possibility of redefining the _reset_vector function
> body, but not the address.

Yes.  The address of the redefined function will be what's placed into
the vector table at the address where the MSP430 will load it on
power-up.  I'm really not clear on how you're trying to accomplish
your goal; you can try to rework the linker script if you want, but as
I understand your intent it won't work.

Looks like you've already discovered SYSRIVECT in SYSCTL, which could
be relevant too if you're working on an MCU that supports it.  At a
high level what you'd need to do is have your modified reset vector
determine whether it needs to do any reconfiguration, do so, then jump
to the reset vector of the selected application.  Accomplishing this
is left as an exercise for the developer and has little to do with
mspgcc, though others here may be able to provide additional help.

Peter

>
> I will try to rework the linker script or my application to something like this:
>
> MEMORY
> {
> ...
> init0: ORIGIN = 0x4400, LENGTH = 0x2
> ...
>
> }
>
> SECTIONS
> {
>   .init0
>   {
>     *(.init0)
>   } > init0
> }
>
> and see if that works.
>
> Best Regards,
> Tomek

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Can the RESET_VECTOR be redefined at compile time to a specific value?

Peter Bigot-4
Re-reading your original post, I had focused on your last sentence,
which in context wasn't the right question.

You don't change anything in the boot loader.  You replace the
memory.ld script for applications with one that puts the .vectors
region somewhere other than 0xff80, and keeps the flash size and
offset from overlapping the bootloader.   The bootloader then copies
from the application .vectors into RAM.  No need to change the main
linker script at all, just provide a different memory.ld.

You could also look at TinyOS and Contiki which I believe have
solutions for this problem.

Peter

On Fri, Apr 18, 2014 at 3:02 PM, Peter Bigot <[hidden email]> wrote:

> On Fri, Apr 18, 2014 at 1:34 PM, Tomek Lorek <[hidden email]> wrote:
>> 2014-04-18 19:40 GMT+02:00 Peter Bigot <[hidden email]>:
>> Thanks Peter!
>>
>>> Yes, if you define a naked function named _reset_vector__ that's in
>>> section .init0 the mspgcc linker scripts will use it instead of the
>>> default one.
>>>
>>> You'd want to do something like:
>>>
>>> __attribute__((__naked__,__section__(".init0")))
>>> void _reset_vector (void)
>>> {
>>>    /* stuff goes here */
>>> }
>>
>> I;m not sure If I understand your hint correctly - the method above
>> gives me the possibility of redefining the _reset_vector function
>> body, but not the address.
>
> Yes.  The address of the redefined function will be what's placed into
> the vector table at the address where the MSP430 will load it on
> power-up.  I'm really not clear on how you're trying to accomplish
> your goal; you can try to rework the linker script if you want, but as
> I understand your intent it won't work.
>
> Looks like you've already discovered SYSRIVECT in SYSCTL, which could
> be relevant too if you're working on an MCU that supports it.  At a
> high level what you'd need to do is have your modified reset vector
> determine whether it needs to do any reconfiguration, do so, then jump
> to the reset vector of the selected application.  Accomplishing this
> is left as an exercise for the developer and has little to do with
> mspgcc, though others here may be able to provide additional help.
>
> Peter
>
>>
>> I will try to rework the linker script or my application to something like this:
>>
>> MEMORY
>> {
>> ...
>> init0: ORIGIN = 0x4400, LENGTH = 0x2
>> ...
>>
>> }
>>
>> SECTIONS
>> {
>>   .init0
>>   {
>>     *(.init0)
>>   } > init0
>> }
>>
>> and see if that works.
>>
>> Best Regards,
>> Tomek

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Can the RESET_VECTOR be redefined at compile time to a specific value?

David W. Schultz
In reply to this post by Tomek Lorek
On 04/18/2014 12:08 PM, Tomek Lorek wrote:

> Is that doable? How can I define in the application’s code that the
> reset vector (0xFFFE) shall contain the bootloader’s init code
> (0x4400)?
>

Why not let the bootloader take care of this?

Once you have a bootloader in place the idea is to let it load the main
program. Since it is in charge of that process it can make sure that the
reset vector gets loaded with the desired address.


--
David W. Schultz
http://home.earthlink.net/~david.schultz
Returned for Regrooving



------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Can the RESET_VECTOR be redefined at compile time to a specific value?

Tomek Lorek
2014-04-18 22:48 GMT+02:00 David W. Schultz <[hidden email]>:

> On 04/18/2014 12:08 PM, Tomek Lorek wrote:
>
>> Is that doable? How can I define in the application’s code that the
>> reset vector (0xFFFE) shall contain the bootloader’s init code
>> (0x4400)?
>>
>
> Why not let the bootloader take care of this?
>
> Once you have a bootloader in place the idea is to let it load the main
> program. Since it is in charge of that process it can make sure that the
> reset vector gets loaded with the desired address.

David, this is exactly what I want to achieve: the bootloader that
fully controls MCU powerup and loading the application's main
function.
The problem arises when you first flash the bootloader and then flash
the application - both use the same vector table (0xFFE0 - 0xFFFE), so
the bootloader's vector table (which has 0xFFFE assigned a value of
0x4400) is overwritten with application's vector table (which has
0xFFFE = 0x5400) (see my first post in this thread).

That is why I either have to overwite bootloader's 0xFFFE cell with a
value of 0x4400 (which I planned to have forced in the application so
that it doesn't use 0x5400) or don't overwrite it at all once flashing
the application (just omit 0xFFFE once flashing) - but the latter I
have no idea how to do :)

Best Regards,
Tomek

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Can the RESET_VECTOR be redefined at compile time to a specific value?

Tomek Lorek
In reply to this post by Peter Bigot-4
2014-04-18 22:23 GMT+02:00 Peter Bigot <[hidden email]>:
> Re-reading your original post, I had focused on your last sentence,
> which in context wasn't the right question.
>
> You don't change anything in the boot loader.  You replace the
> memory.ld script for applications with one that puts the .vectors
> region somewhere other than 0xff80, and keeps the flash size and
> offset from overlapping the bootloader.   The bootloader then copies
> from the application .vectors into RAM.  No need to change the main
> linker script at all, just provide a different memory.ld.

I guess that is the recipe for the vector table stored in RAM
(SYSRIVECT bit of SYSCTL set). I already did this and it works ok,
although I let the application to register its interrupt handlers
itself, the SYSRIVECT is set by the bootloader.

But still I need to know if it's doable to make the bootloader use
just reset vector and the application to define all interrupts except
reset. It's like to create the application that has no init, I'm ok
with it because I know the bootloader has and expect the bootloader to
be called every time the MCU powers up.
Of course I can program only by bootloader (and then intentionally
skip 0xFFFE address) but I wanted a handy and convenient solution that
could be flashed with mspdebug.

Thanks for your help!

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Can the RESET_VECTOR be redefined at compile time to a specific value?

Peter Bigot-4
Yes, it's doable.  I haven't done it myself, so you're mostly on your
own, but the approach I'd take is to have a bootloader application
with unique vectors, text, and data sections, compiled to an object
file.  I.e., it would have symbols going into .bldr.vectors,
.bld.text, .bld.data, etc.  I'd expect to need to use elf editing
tools to rename the sections in this object file.

Then I'd build application object files using the standard section names.

Finally, I'd like the application with the bootloader using a custom
linker script that put the .bldr.* sections in the "right place"
(i.e., .bldr.vectors at 0xff80, and its text and data into distinct
parts of the flash and ram regions) and the non-.bldr sections in
other parts of flash and ram.

The result would be a single image combining bootloader and
application which could be flashed with mspdebug without having to
figure out how to erase only the application parts of the memory,
leaving the bootloader.

Of course, since this would couple the application to the bootloader
it's not clear what value the bootloader has.  Presumably you still
need to build applications that do not include the bootloader, but you
could use the same script for that and just not include the bootloader
object file when doing the link.  How you get that onto the MCU is a
different problem (which presumably involves the ability to tell
mspdebug to erase only the application parts of the flash and copy in
a new application, leaving the bootloader flash sections untouched).

I'm afraid that general idea is the best I can do for you; you'll have
to experiment to get a working solution.

Peter


On Fri, Apr 18, 2014 at 4:27 PM, Tomek Lorek <[hidden email]> wrote:

> 2014-04-18 22:23 GMT+02:00 Peter Bigot <[hidden email]>:
>> Re-reading your original post, I had focused on your last sentence,
>> which in context wasn't the right question.
>>
>> You don't change anything in the boot loader.  You replace the
>> memory.ld script for applications with one that puts the .vectors
>> region somewhere other than 0xff80, and keeps the flash size and
>> offset from overlapping the bootloader.   The bootloader then copies
>> from the application .vectors into RAM.  No need to change the main
>> linker script at all, just provide a different memory.ld.
>
> I guess that is the recipe for the vector table stored in RAM
> (SYSRIVECT bit of SYSCTL set). I already did this and it works ok,
> although I let the application to register its interrupt handlers
> itself, the SYSRIVECT is set by the bootloader.
>
> But still I need to know if it's doable to make the bootloader use
> just reset vector and the application to define all interrupts except
> reset. It's like to create the application that has no init, I'm ok
> with it because I know the bootloader has and expect the bootloader to
> be called every time the MCU powers up.
> Of course I can program only by bootloader (and then intentionally
> skip 0xFFFE address) but I wanted a handy and convenient solution that
> could be flashed with mspdebug.
>
> Thanks for your help!

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Can the RESET_VECTOR be redefined at compile time to a specific value?

Tomek Lorek
Thank you for your help! That case exercises my brain a lot :)

2014-04-18 23:52 GMT+02:00 Peter Bigot <[hidden email]>:

> Yes, it's doable.  I haven't done it myself, so you're mostly on your
> own, but the approach I'd take is to have a bootloader application
> with unique vectors, text, and data sections, compiled to an object
> file.  I.e., it would have symbols going into .bldr.vectors,
> .bld.text, .bld.data, etc.  I'd expect to need to use elf editing
> tools to rename the sections in this object file.
>
> Then I'd build application object files using the standard section names.
>
> Finally, I'd like the application with the bootloader using a custom
> linker script that put the .bldr.* sections in the "right place"
> (i.e., .bldr.vectors at 0xff80, and its text and data into distinct
> parts of the flash and ram regions) and the non-.bldr sections in
> other parts of flash and ram.
>
> The result would be a single image combining bootloader and
> application which could be flashed with mspdebug without having to
> figure out how to erase only the application parts of the memory,
> leaving the bootloader.
>
> Of course, since this would couple the application to the bootloader
> it's not clear what value the bootloader has.  Presumably you still
> need to build applications that do not include the bootloader, but you
> could use the same script for that and just not include the bootloader
> object file when doing the link.  How you get that onto the MCU is a
> different problem (which presumably involves the ability to tell
> mspdebug to erase only the application parts of the flash and copy in
> a new application, leaving the bootloader flash sections untouched).
>
> I'm afraid that general idea is the best I can do for you; you'll have
> to experiment to get a working solution.
>
> Peter
>
>
> On Fri, Apr 18, 2014 at 4:27 PM, Tomek Lorek <[hidden email]> wrote:
>> 2014-04-18 22:23 GMT+02:00 Peter Bigot <[hidden email]>:
>>> Re-reading your original post, I had focused on your last sentence,
>>> which in context wasn't the right question.
>>>
>>> You don't change anything in the boot loader.  You replace the
>>> memory.ld script for applications with one that puts the .vectors
>>> region somewhere other than 0xff80, and keeps the flash size and
>>> offset from overlapping the bootloader.   The bootloader then copies
>>> from the application .vectors into RAM.  No need to change the main
>>> linker script at all, just provide a different memory.ld.
>>
>> I guess that is the recipe for the vector table stored in RAM
>> (SYSRIVECT bit of SYSCTL set). I already did this and it works ok,
>> although I let the application to register its interrupt handlers
>> itself, the SYSRIVECT is set by the bootloader.
>>
>> But still I need to know if it's doable to make the bootloader use
>> just reset vector and the application to define all interrupts except
>> reset. It's like to create the application that has no init, I'm ok
>> with it because I know the bootloader has and expect the bootloader to
>> be called every time the MCU powers up.
>> Of course I can program only by bootloader (and then intentionally
>> skip 0xFFFE address) but I wanted a handy and convenient solution that
>> could be flashed with mspdebug.
>>
>> Thanks for your help!

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Can the RESET_VECTOR be redefined at compile time to a specific value?

John Griessen-3
In reply to this post by Peter Bigot-4
On 04/18/2014 04:52 PM, Peter Bigot wrote:
> The result would be a single image combining bootloader and
> application which could be flashed with mspdebug without having to
> figure out how to erase only the application parts of the memory,
> leaving the bootloader.
>
> Of course, since this would couple the application to the bootloader
> it's not clear what value the bootloader has.


If the bootloader does not stay available through the standard compile cycle,
all of the rely-on-it value is gone.  IOW, you could do a pilot error
mistake in compiling to install a dead bootloader and be stuck.

So, you would have to define strict ways of doing compiles to
stay productive.  So you could rely on the bootloader
being there and working.

Not that I have any experience in writing bootstrapping code...but
I have done some chip circuits, where you decide what you want in
a meeting, then make it happen in hardware with a code method in mind.

Just a point to ponder.

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Can the RESET_VECTOR be redefined at compile time to a specific value?

Michiel Konstapel-2
In reply to this post by Tomek Lorek
You may be able to use the same approach TinyOS does, using some linker flags. An example for an msp430f1611:

CFLAGS += -Wl,--section-start=.text=0x4a00,--defsym=_reset_vector__=0x4000

So when compiling/linking the application, it moves the text segment up and defines the _reset_vector__ to point at the bootloader. You don't even need a separate linker script.

However, redefining __reset_vector_ apparently makes the compiler discard some symbols referenced from it, which are then manually added back in. The full sequence is:

CFLAGS += -Wl,--section-start=.text=0x4a00,--defsym=_reset_vector__=0x4000
# Pull back in mspgcc CRT code discarded by the redefinition of _reset_vector__
CFLAGS += -Wl,--undefined=__init_stack
CFLAGS += -Wl,--undefined=__low_level_init
CFLAGS += -Wl,--undefined=__do_copy_data
CFLAGS += -Wl,--undefined=__do_clear_bss
CFLAGS += -Wl,--undefined=__stop_progExec__
CFLAGS += -Wl,--undefined=_endless_loop__

HTH,
Michiel

> -----Original Message-----
> From: Tomek Lorek [mailto:[hidden email]]
> Sent: Friday, April 18, 2014 19:09
> To: [hidden email]
> Subject: [Mspgcc-users] Can the RESET_VECTOR be redefined at compile
> time to a specific value?
>
> Hi,
> My use case is the following: I have a bootloader (up to 4K in size,
> residing at 0x4400 to 0x5400) that has a main() function and
> application (starting from 0x4800) – they are organized as 2 separate
> projects (I want the bootloader to be flashed only once and not
> changed later).
>
> I am using mspgcc.
>
> Bootloader and application linker scripts are defined so that their
> .text sections (that go to “rom” memory region) are separated but they
> use the same “vector” memory region for .vector section (although the
> bootloader does not use any interrupts other than reset):
>
> bootloader’s linker script excerpt:
> MEMORY {
>   …
>   rom (rx)         : ORIGIN = 0x4400, LENGTH = 0x1000 /* END=0x5400,
> size 4K - bootloader code */
>   rom_app (rx)     : ORIGIN = 0x5400, LENGTH = 0xab80 /* END=0xff80,
> size 43904 - the field-updatable application */
>   vectors          : ORIGIN = 0xff80, LENGTH = 0x0080 /* END=0x10000,
> size 128 as 64 2-byte segments */
>   …
> }
>
> and the application’s linker script excerpt:
>
> MEMORY {
>   …
>   rom (rx)         : ORIGIN = 0x5400, LENGTH = 0xab80 /* END=0xff80,
> size 43904 */
>   vectors          : ORIGIN = 0xff80, LENGTH = 0x0080 /* END=0x10000,
> size 128 as 64 2-byte segments */
>   …
> }
>
> I need the bootloader’s init code and main() function be executed upon
> power up of the microcontroller. And this would be the case if I only
> flash the bootloader’s .elf onto the flash (0xFFFE pointing to
> bootloader’s main() function).
>
> But when I then program the application’s image onto the flash the
> 0xFFFE will point to the application’s reset vector which is not a
> bootloader anymore. I'd like to configure my application so that it
> always fills 0xFFFE with a fixed address (0x4400).
>
> The rest of the story is that when bootloader is started then of
> course the bootloader needs to jump to and execute the application’s
> entry point (0x5400) including the app's watchdog preparation, stack
> init etc.
>
> Is that doable? How can I define in the application’s code that the
> reset vector (0xFFFE) shall contain the bootloader’s init code
> (0x4400)?
>
> Best Regards,
> Tomek
>
> -----------------------------------------------------------------------
> -------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and
> their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Mspgcc-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Loading...