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 <tlo...@gmail.com> wrote:
> 2014-04-18 19:40 GMT+02:00 Peter Bigot <big...@acm.org>:
> 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
> Mspgcc-users@lists.sourceforge.net
> 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
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
