In the first post, on the first page of this thread. The post has the TOC of the FAQ as it's text, and below that text there is a box with the heading "bootloader_faq.pdf", and in that box, to the right, is a link "Download".

Or did you look for it before you signed up and logged in, but not afterward? If so, then go back now and it will be there.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

By going to the first page of this thread, locating the very first post, and downloading the document at the link labelled "Download".

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

OK, that was very helpful. turns out the link is hidden way to the right, so unless you scroll to the right its invisible.

I have two more questions for you kind folks:

1) I'm trying to write flash with the SPM instruction on a ATMega128. Let's say I'm trying to write the 64 words (128 bytes) located at E000 in my address map. How do I set Registers 31, 30 and port RAMPZ to do that. The ATMEL docs on the subject just spin my head around and around and around...

2) Ok so I want to erase the page that holds my interrupt vectors in flash on the ATMega128.
I set bit 0 in RAMPZ to zero. I set SPMSCR with an STS instruction to 3. I load Registers 31 and 30 with zero then issue the spm instruction. Interrupts are disabled. I wait a second or two. The value of SPMSCR is still 0x3. What did I do wrong?

The Z-pointer together with RAMPZ are used to address the SPM commands. For details on how to use the RAMPZ, see â€œRAM Page Z Select Register â€“ RAMPZâ€ on page 14. Since the Flash is organized in pages (see Table 123 on page 291), the program counter can be
treated as having two different sections. One section, consisting of the least significant bits, is addressing the words within a page, while the most significant bits are addressing the pages.
This is shown in Figure 134. Note that the page erase and page write operations are addressed
independently. Therefore it is of major importance that the Boot Loader software addresses the
same page in both the page erase and page write operation. Once a programming operation is
initiated, the address is latched and the Z-pointer/RAMPZ can be used for other operations.
The only SPM operation that does not use the Z-pointer/RAMPZ is setting the Boot Loader Lock
bits. The content of the Z-pointer/RAMPZ is ignored and will have no effect on the operation.
The (E)LPM instruction does also use the Z-pointer/RAMPZ to store the address. Since this
instruction addresses the Flash byte by byte, also the LSB (bit Z0) of the Z-pointer is used.

The key things in this are the fact that addressing is BYTE not WORD addressing and therefore Z can only access the first 64K but this can then be extended to the second page with RAMPZ. I take it by E000 you mean the word address so in byte addressing that is
1C000. So you'd set RAMPZ to 1 and Z to C000.

2) suggest you show the code but as this thread is not for diagnosing general SPM problems (only for discussing the FAQ) I suggest you do this in a new thread in AVR Forum.

BTW as for not being able to download the PDF. Do you not see the first page as:

thanks for clarifying the Z pointer addressing. The document you quote sends you into three different document sections and addresses several unrelated issues. The result is that it does in fact leave the reader unclear about the z pointer addressing. I would recommend a bit oriented diagram instead of the combined diagram/word descriptions used.

I checked again and in fact if you don't know the forum, you have to be clairvoint or happen to scroll. I acatually had to use a google lookup to find it the first time.

I appoligize for posting to the wrong forum. That's why they call us newbies :)

I can not make the download link "invisible" (scrolled out) unless I also make half the text or so also scrolled out to the right. DUT: Firefox 3.6.13.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Hi
I'm afraid I too am having problems accessing this pdf.
First I could not see the box at the bottom of the first item but after logging in sure enough after scrolling miles to the right there it was. (its as if the box is two normal page widths wide). Anyway clicking on down load I get a loading bargraph at the bottom of the page and then a complete blank except for an odd icon in the top left hand corner of the screen. I am using Nitro pdf reader. Its been ok so far on all other pdf's Ive downloaded - and there are many.....
Any ideas?
Dave H

after scrolling miles to the right there it was. (its as if the box is two normal page widths wide)

The box is always as wide as the page is, i.e. as wide as the widest post in the current page. If the page is "wider than reasonable" then it might be due to

- Someone having produced a post that makes the page very wide (long line that can not be broken i.e. no spaces etc, or large/wide picture attached), or

- The browser used has some quirk rendering pages. Right now I'm typing this with FireFox, and the page fits on a 1280 wide screen. Mind you, I have clicked the Maximize link (no not any button on the browser window title bar os similar - there is a link at the top of every AVRfreaks page). This simple manouvre lets you utilize the whole browser window width for something useful, rather than wasting perhaps half of it on some green goo that someone at Atmel decided he could use my presious and expensive screen pixels to display.

Quote:

Any ideas?

Try another browser?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Well I think I've cracked it, (not being able to download the TUT)
I used my wifes laptop running XP and with Adobe Acrobat reader, (on my computer I use Nitro pdf reader which has worked perfectly up to now), and although the page for this post is VERY WIDE (? only when logged in) by scolling to the right I get to the download link and pressing this loads up the pdf. (with my PC all I got was a blank page)

Well I have to say it was well worth the effort!
I take my hat off to those who put in the time and effort to compile these pearls of information in such a reasoned and logical and concise way - even I understood half of it - fortunately the relevent half.

I'd like to suggest a modification to the tutorial. For people who are trying to learn about bootloaders, this tutorial doesn't have much of an explanation of the higher level concepts. It's definitely a good reference after you've learned the basics, but we don't have a guide to help people get to that point. I just went through this process so I thought I'd point this out while it's fresh in my mind.

The biggest stumbling block I've seen in countless threads as well as experienced is the leap from putting the bootloader on the mcu and then actually using it. Every document I've seen for AVR Dude, avrfreaks tutorials, posts, etc. has people asking the same questions. Simply put, a section titled "This is how you actually use the bootloader (with examples)" would have saved me many hours of trying to understand what comes next. This tutorial has a one-liner with no specific information, which didn't really help me at all.

Quote:

Two step approach: Program your bootloader with an external programmer as described in question #6. You will probably also want to set fuses, including BOOTSZ and BOOTRST, at the same time. Then simply use the bootloader's normal communication mechanism to transfer and program the application.

That's great and all, but if you don't know how to use it in the first place, this statement only frustrates you more.

I'd be happy to work on this if you acknowledge that it would be put in the FAQ if I provided it.

We didn't write this for beginners. It's for those actually interested in WRITING a bootloader. They are bound to know how you use one!

Feel free to start a new tutorial thread with a beginners guide to using bootloaders - all contributions welcome here.

Don't you think it would be good if it could be combined into one resource for everyone to reference? I don't think it's a complicated enough topic for two. The beginner stuff could simply be an introductory section that advanced users could skip.

If I started a thread for beginners, the name would likely be confusing since this one doesn't really mention that it is for writing bootloaders. Bootloader FAQ implies a broader scope than creating one. When I was trying to learn about bootloaders, this seemed like a good place to start, so I read most of the document hoping it would have something beginner friendly.

Great write up! It was my primary source for getting my wireless version of the AVR231 bootloader going.

Maybe it's obvious, but I would make one suggestion--provide a little detail on how to define ADDR_APP_RUN referenced here:

// Bootloader code
const uint8_t app_run = eeprom_read_byte(ADDR_APP_RUN);
if(app_run == APP_RUN)
{
// In case the app is faulty, clear the eeprom byte so that
// the BL will run next time. A properly running app should
// set this back to APP_RUN.
eeprom_write_byte(ADDR_APP_RUN, 0xFF);
run_application();
}
// Only run the bootloader once, then go back to the app
// (comment out the next line during app development)
eeprom_write_byte(ADDR_APP_RUN, APP_RUN);

I don't think you can just #define or hardcode ADDR_APP_RUN to something like 0x0 in a header file shared between the bootloader and application. The compiler will assign one of your application variables to the same eeprom address. For example, in my application code I have statements like this:

uint8_t EEMEM ee_ReceiveA=RF_CHANNEL_A

The compiler can assign whatever address it wants to ee_ReceiveA--it will likely be 0x0 if that's the first EEMEM variable you define.

If the bootloader has something like this:

uint8_t EEMEM ee_app_run

then one can look up the address of ee_app_run from the booloader map or .lss and access the associated eeprom data in both the bootloader and application using that fixed address.

But, doesn't something also have to be done in the application to reserve a EEMEM byte at that same address? One could declare ee_app_run before any other EEMEM variables in both the application and bootloader code. But, is it OK to depend on the linker to put the first EEMEM declared at 0x0?

What's the recommended way to define an ADDR_APP_RUN and share it between the bootloader and application code?

You are quite right. No one should ever be using absolute addressing in the EEPROM. You don't do it with variables in RAM - you just place them by name and the linker finds addresses for them. That should be true for EEPROM too. So he should have had something like:

uint8_t app_run_inEE EEMEM;

Then pass &app_run_inEE as the address parameter to the eeprom_*() functions. Good spot.

"I guess.."
I hear you. It "feels wrong" to use an absolute address. At least I didn't have to answer the questionL
"Why would you ever want to define an address for variable in EEPROM".
If you think about it, application code can NEVER be independent from the bootloader code, IF you want the ability to initiate load of new code from the applicaiton (I do).
The application code and bootloader code have to have a common understanding of the mechanism used to initiate load of the new code, regardless of what that mechanism is.
In this case, the mechanism jis a location in EEPROM, but regardless of the mechanism, since both pieces of code have to understand the mechanism, they can't be totally independent.
So, given that they can't be independent, wouldn't it make sense to always build them together? Maybe use some linker mechanism to locate the application code at 0x0 and the bootloader code at the address defined by the BOOTSZ fuses?
That way you wouldn't have to fix an address for the "shared" EEPROM address.

Good practical suggestion, though. Use the highest EEPROM address and everything should be OK. I used the lowest and ended up "getting bit".