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

Tomek Lorek <[email protected]>
Newsgroups gmane.comp.hardware.texas-instruments.msp430.gcc.user
Message-ID <CAP62dvCoegNi0CfOf5b204qO3T4OZ+7JF5=Cw-ZHxHEgET1W9g@mail.gmail.com>
2014-04-18 22:23 GMT+02:00 Peter Bigot <[email protected]>:
> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.