avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] boot API example


From: E. Weddington
Subject: Re: [avr-libc-dev] boot API example
Date: Thu, 05 Feb 2004 15:32:58 -0700

On 5 Feb 2004 at 13:57, Theodore A. Roth wrote:

> Hi,
> 
> I'm in the process of writing a xmodem based bootloader and was just
> studying the API example in the docs.

Oh, bother.

Mea culpa and my apologies for any bad examples, inconsistencies, and 
incompleteness.
 
> There's some mistakes in that example that really need fixing.
> 
>   - It doesn't include <avr/boot.h>.

Yup.
 
>   - There's a buffer overflow: the buffer array is 8 bytes and in the
>     show() function call it appears to be loaded with 16 bytes of data.

show() is contrived anyway (as it's not declared or defined). Feel free to rip 
it out.
 
>   - I don't think that sei() should be used since it would enable
>     interrupts even if they were never enabled in the first place.
>     Better to show more flexible code in the example.

Yup. 

> Also,
> 
>   - It should show that the function needs to placed in the .bootloader
>     section and show an example of how to set the starting address of
>     the .bootloader section via the LDFLAGS make variable.

Yup. The FAQ has sorta some stuff on how to relocate.
 
>   - The utoa() library function should propably not be used if this
>     example is used in a standalone bootloader program.

Of course.
 
>   - It's not where this function should live: RWW or NRWW. If it's a
>     real bootloader, it needs to go in NRWW. As it stands, there's the
>     risk of clobbering the function if it overlaps ADDRESS.

Sorry for missing that.
 
>   - There really should be mention of the RAMPZ register somewhere in
>     the example stating that the API handles it for you automagically
>     (I had to go to the source to figure that out).
> 
> Yes, I know the example is a contrived one, but it would be better to
> show a less contrived example in this case since there are so many
> gotchas involed in using SPM anyways.

Agreed. 


> If nobody else wants to handle this, I'll add it to my TODO list, but no
> guarantees on when it will get done.

I'm busy right now, so add it to yours. Also, until you upgrade the autotools 
version for avrlibc, I can't build and check the doxygen output (due to Cygwin 
weirdness).

While we're at it, there are also issues that was brought up by Markus Pfaff 
back in September
here:
<http://mail.gnu.org/archive/html/avr-libc-dev/2003-09/msg00070.html>
here:
<http://mail.gnu.org/archive/html/avr-libc-dev/2003-09/msg00072.html>
and here:
<http://mail.gnu.org/archive/html/avr-libc-dev/2003-09/msg00071.html>

 
> On a similar note, regarding this message:
> 
>   http://mail.gnu.org/archive/html/avr-libc-dev/2002-12/msg00067.html
> 
> Once I get it working, I can provide my bootloader as a working example
> in the docs if there is desire. I'll probably have it done by tomorrow
> as it's nearly working now (the xmodem part is done, I'm just adding
> the SPM stuff now).
> 

Let me know if I can be of help.

Eric




reply via email to

[Prev in Thread] Current Thread [Next in Thread]