On 30 April 2015 at 04:03, Eric Decker <cire...@gmail.com> wrote:
> On Wed, Apr 29, 2015 at 9:06 AM, Li, Wenting <luth...@gmail.com> wrote:
>
>>
>> 1. I want to put an application in the bootloader section and the other
>> part in the applicatioin section, because I need the capability to write to
>> internal flash. But the whole TOS image is too big to fit in bootloader
>> section. So can I selectively choose a component to stay in bootloader
>> section, and the other parts outside.
>>
>
> no
>
Make that a "no, not easily" :)
For what you're wanting to do, you'll definitely want to use TosBoot. Even
so, with an AVR you'll need a few extra tweaks to work with/around the
flash programming restrictions. It's been a few years since I worked in
this area, but as a very brief summary, for remote firmware upgrade you
need to:
- Use TosBoot to provider basic loader functionality, and get ensure it's
installed in the privileged/bootloader area of the flash.
- Put the flash writing/erasing routines for the AVR into TosBoot, and the
function prototypes for them in some header file somewhere.
- Generate a linking library from the TosBoot binary, containing only the
symbols for your flash read/write functions.
- Create the volumes-{something}.xml to specify partitioning of your flash
- you'll need at least two application volumes to allow downloading and
switching to new firmware. There's a TEP or intro on how all that bit works
(I've forgotten most of it by now *cough*); It's probably together with the
rest of the TosBoot information.
- Add "-Wl,-R$(path_to_above_generated.lib)" to your application Makefile's
LDFLAGS, to allow the linker to resolve your flash read/write functions.
- Include the header file for the flash read/write in whichever module
handles receiving new firmware data, and call them from there. Since these
functions actually reside in the boot loader area of the flash, they're
allowed to do the reprogramming. You're effectively sharing these functions
between both TosBoot and your application. This is the key to making it all
work.
- All the other details that I've glossed over or forgotten about :)
- And finally, be very very very careful if you ever need to make changes
to your TosBoot, since if you change the address of the read/write
functions, Things Will Break(tm). If possible, place those functions at
fixed addresses to avoid such headaches.
> How can I do it if TinyOS only allows the upload of one packaged system
>> image?
>>
>
> you can't in the context of TinyOS. The question above is outside the
> scope of how TinyOS gets built.
>
> You are actually asking a question about how to you make use of the
> embedded atmel environment. And how do you load two different pieces of
> code into the Atmel flash and have them cooperate in some fashion.
>
> TinyOS doesn't directly support doing those kinds of things.
>
While, as Eric says, there's no direct support for it, the structure does
work quite well for slotting it in though, largely thanks to TosBoot.
> You can do this but it is outside the scope of how TinyOS works. So it is
> something that you would have to figure out.
>
Having been in the position of having to figure those things out, allow me
to point you at our (now somewhat outdated) TinyOS fork with support for
the atxm256, including the above mentioned boot loader / reprogramming
support. The most interesting file to peruse is probably the TosBoot
Makefile:
https://github.com/DiUS/tinyos-siflex02/blob/master/tos/lib/tosboot/Makefile
The siflex02 & modflex related targets have the relevant bits.
Getting it all to work isn't what I'd call trivial, but it *is* doable if
you're willing to put the time into it!
Good luck,
/Johny
--
Johny Mattsson
Senior Software Engineer
DiUS Computing Pty. Ltd.
*where ideas are engineered *
_______________________________________________
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
