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" <wylder.ke...@gmail.com> 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 <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
