----- Ursprüngliche Nachricht -----
Von: Alex Stefan
Gesendet am: 09 Aug 2011 07:57:19
JMGross <mspgcc <at> grossibaer.de> writes:
>> My own approach for this was as follows (note that my 'bootloader' is only a
>> 'boot copier'.
>> The new firmware has been received by the old firmware and stored (with CRC)
>> in a free flash region.
>> The priciple is the same, however, only the bootloader is way smaller this
>> way :)
>That's a very good idea indeed. I only need a boot copier. For now, the linker
>file of the main appliatcion was tweaked so that the reset vector points to the
>start of the bootloader zone. A real issue appears if programming the
>bootloader after the main application as they each write the same interrupt
>vector table.
>Luckily, the bootloader doesn't need any interrupts to function. For now :).
Well, it needs the reset vector, and it needs to be @0x0FFFE.
>> I created three new flash segments. One, bootvect, resides where the original
>> interrupt vector tables was.
>> The old vector table is moved down by 1k (or whatever mutliple of 512 bytes
>> you need)
>> second section is just below and consists of a set of indirect jumps.
>> third section is for the bootloader and below the other two.
>> The bootvect section is filled with references to the jumpsection. One jump
>> per vector. Except the reset vector.
>> The reset vector of course points to the bootloader.
>> So every interrupt except a reset will jump into the jumptable.
>> The jumptable is filled with indirect jumps jumping indirectly on the content
>> of the moved application
>> interrupt vector table.
>> And the bootloader, if it decides that there is nothing to do or everythign
>> is done, jumps indirectly over the reset vector in the 'real' vector table.
> As I said, seems like a very good idea, but there's one thing I don't
> understand. Why do you need the 'indirect jumping zone'. Why wouldn't it be
> possible to program the vector in bootvect to jump directly to the interrupt
> vector table of the application? Except, of course, the reset vector which
> will
> still point to the bootloader.
The 'real' vector table @0x0FFxx contains addresses only. And the
application vector table too. So if the real vector table would simply point to
the application vector table, it would try to execute the addresses there as
instructions
The reason why I preferred the two vector tables and one jumptable
(actually not a table but an array of jump instructions, as you can see
in the example quoted below) is that this way the real vector table never
needs to be erased, so there will be never a situation in which the reset
won't point to the bootloader.
If the real vector table would contain the applicaiton vectors, it would need
to be
updated (along with some more flash, as 512 bytes are erased together,
either wasting this as unused flash or needing a backup), and if during update
somethign goes wrong (a power fail, maybe), the device will no longer respond
nor will it recover.
>> 0x5C00-0xFB7F application flash
>> 0xFB80-0xFBFF applcation interrupt vector table
>> 0xFC00-0xFE7F bootloader
>> 0xFE80-0xFF7F jumptable (br &0xFB80; br &0xFB82;...)
>> 0xFF80-0xFFFF 'real' vector table, pointing to bootloader start or
>> jumptable.
>> (0xFE80, 0xFE84, 0xFE88,...)
> How do you declare constant blocks in the source file so that they are
> included
> 'as they are' in the binary file and then onto the flash.
That's automatic. The assembly code doesn't change, doesn't have any references
outside itself (except for the fixed addresses to the moved applicaiton vector
table)
and is placed in segments that are only used by itself.
So assembling and linking it (with the same linker ocmmand file) results in the
same binary code generated, no matter what the application code is.
If you update the firmware usign JTAG, the bootloader is overwritten with the
same
code (so JTAG can do a mass erase and just copy the whole binary), the
bootloader itself will simply ignore/not copy into its own area, even if the
new firmware
contains a new copy.
Drawback: the bootloader cannot/will not update itself. But if this is needed,
there's
still JTAG, or a specific firmware that does this job and is uploaded just for
this
purpose. With the forementioned risk of leaving the device useless if something
goes
wrong.
>From the other post:
> Ok, but why can't we have something like:
> 0x5C00-0xFB7F application flash
> 0xFB80-0xFBFF applcation interrupt vector table
> 0xFC00-0xFE7F bootloader
> (NOT)0xFE80-0xFF7F jumptable (br &0xFB80; br &0xFB82;...)
> 0xFF80-0xFFFF 'real' vector table, pointing to bootloader start or
> jumptable.
> (0xFB80, 0xFB84, 0xFB88,...)
> instead of:
> 0x5C00-0xFB7F application flash
> 0xFB80-0xFBFF applcation interrupt vector table
> 0xFC00-0xFE7F bootloader
> 0xFE80-0xFF7F jumptable (br &0xFB80; br &0xFB82;...)
> 0xFF80-0xFFFF 'real' vector table, pointing to bootloader start or
> jumptable.
> (0xFE80, 0xFE84, 0xFE88,...)
Because both vector tables only contain addresses, not instructions.
And an address pointing to an address would make the CPU try to execute the
second
address as instruction.
It would be possible to 'blowup' the application interrupt vector table into an
array of jump
instructions which directly jump to the ISRs, but this is incompatible with the
way the
vector table is built in MSPGCC. There are only 2 bytes per vector and the
jumps would
require 4, so all header files with the vector definitions had to be changed.
Having an array of indirect jumps that use the application vector table for
fetching the
destination addresses is the most compatible way to do things.
In fact, if you have an applciaiton that uses flash from bottom up
(except for the vector table), you can take the binary and just change the
start address
of the vector table (a simple one-line text replacement in TI.txt format) and
the resulting
binary is compatible for upload (not with JTAG, as the bootloader is missing).
Or the bootloader does this adjustment 'on-the-fly'. This way, it wouldn't be
necessary
to alter the linker script at all, except for the bootloader itself.
On MSPs with a rewritable bootloader, things are different, There would be no
need
to do the vector table buffering, as the BSL code is called before everything
else,
including the reset vector. However, reprogramming the BSL is tricky and may
easily
render the device useless (monworking BSL and deactivated JTAG).
JMGross
------------------------------------------------------------------------------
uberSVN's rich system and user administration capabilities and model
configuration take the hassle out of deploying and managing Subversion and
the tools developers use with it. Learn more about uberSVN and get a free
download at: http://p.sf.net/sfu/wandisco-dev2dev
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
