SparkFun Forums

[bt101]

Hi - I'm going bonkers trying to get a boot loader working.
The doc for the 644p shows that it has 64k of flash. The tables for the boot loader addresses show addresses like 7000h 7800h, etc. These addresses are less than half way to the 64k, so I am assuming that they are some sort of word addressing rather than byte addressing (I poured through the spec sheet and it is terribly unclear). Anyway, I downloaded and compiled the Sanguino bootloader and it is using an address of F800h. This address is nowhere near the 7xxx address. Just what is going on here? Does a boot address of 7000h mean that it will jump to that address and I should compile my code for 7000h?

Thanks

[stevech]

AVR boot area in Flash is spoken about as words (16 bits). The smallest possible boot area size among the many AVR chips is 256 words (512 bytes). The choice of boot area size is governed by the size of the bootloader code you plan to install using an ISP programmer device, plus the AVR chip's choices of sizes (they vary). The size choice is given by the "fuse" (configuration settings) that you apply using an ISP device.

Some people prefer a very spartan/small bootloader, small as possible as that flash area is lost to the bootloader, not available to the application code. And the sizes of the boot area varies in steps of powers of two. So a bootloader one byte too large might cost a lot.

One bootloader with PC-side GUI software, free, with AVR source code for Atmel's Studio - you configure constants to choose chip, crystal, baud - is this, among many... (this one's 512 bytes)

http://www.avrfreaks.net/index.php?modu ... tem_id=625

The PC side is easy to use, if I don't say so myself (!)

I've not seen a C language bootloader that squeezes into 512 bytes.

[bt101]

Just so I understand...
When the AVR spec sheet says that boot code starts at address 7000h, that is an incorrect address? I should compile my code with address 2x7000h=E000h?

[stevech]

You set the origin address of the boot loader to match the chip and fuse settings of your choice. Let's say the bootloader fits in 512 bytes (256 words). So the origin would be chip's flash memory-size less 512 bytes.

The AVR will do a reset and go to the bootloader (if you set the fuses for it to do so). It will jump to the location at the beginning of the boot block, based on what you set the boot area size to, in the fuse settings using the ISP device.

Again, just look at the example I posted for you.

[bt101]

Thanks, yes I already know about fuse settings etc.
I just need to know if the 644p doc is correct. When I select fuse settings for a bootloader address of 7000h (as per the document) does the CPU really boot at that address, or is that value incorrect. I can't imagine that the bootloader would start at an address that is less than half way through the memory (it should be near the end of memory). I'm wondering if there is some mistake in the doc.

[n1ist]

The bootloader address is a word address, not a byte address. So the bootloader starts at 7000h words from 0 or at 0xE000.

Not sure why they love to mix byte and word addresses when it comes to bootloaders...
/mike

[bt101]

Thanks. Got-r-workin now.

[stevech]

The bootloader address is a word address, not a byte address. So the bootloader starts at 7000h words from 0 or at 0xE000.

Not sure why they love to mix byte and word addresses when it comes to bootloaders...
/mike

Not sure you grasped this: The boot code size is variable. You choose, based on size of bootloader you want to use.

Address varies according to bootloader size.

Bigger bootloader, address is smaller number. And vice-versa.

You CAN put a small bootloader and a lower-than-needed address. But you'll waste a lot of Flash memory doing so.

[bt101]

I'm not too sure about the other AVR chips, but in the 644p you can only choose 4 bootloader addresses. According to the doc they are 7000, 7800, 7c00, and 7e00.
I'm OK with that, I just gotta choose one where my boot code will fit.
The problem I was having is that these addresses didn't sound right.
n1ist confirmed that these addresses are really the correct address divided by 2. So the boot addresses are really e000, etc, etc. So I had to compile and load my code at address e000 and it worked. I gotta agree with n1ist, it's hard to read/trust the docu when they use byte or word addresses without qualifying them.

[stevech]

AVR documentation.
Word addresses versus byte address.
Byte address = Word address times two.
And vice-versa, dividing.

[signal7]

... or taking it a step further, you could say flash is always addressed as words - not bytes. RAM on the other hand, is addressed as individual bytes.

I ran into this some time ago when I had a program storing some static response messages in flash so as to avoid using what little amounts of RAM were available.

[stevech]

... or taking it a step further, you could say flash is always addressed as words - not bytes. RAM on the other hand, is addressed as individual bytes.

I ran into this some time ago when I had a program storing some static response messages in flash so as to avoid using what little amounts of RAM were available.

But alas, look at the AVR's LPM instruction. It uses a byte address to retrieve one byte from flash (program memory). Per Atmel..
"The 15 most significant bits select the word address in program memory. Because of this, the word address is multiplied by 2 before it is put in the Z register."
And bit 0 of the Z register selects which byte is read.

The LPM instruction used generated by compilers when you place constants like strings in flash and declare them as such to the compiler. Then there are special variants in the C library for constants in flash, such as WINAVR's library routing "printf_P()" and macro PSTR("hello") to store strings in flash.

This is all a PITA kludge for compilers that don't have an intrinsic concept of the dual address space Harvard architecture. The commercial compilers for AVRs (and PIC I suppose) do support this much better. But the C code for such has to be modified extensively if you rehost that C code to a von Neuman single-address-space CPU like ARM7 or 8051.