AVR Freaks

To be honest I'd forgotten I'd even added Zip files and there's no guarantee they're going to be anyway up to date.
.
All professional engineers are going to be using SVN and/or Git anyway so it's pretty trivial to pull it as an SVN checkout and that way you KNOW you have the up to date files.

Well if you built the bootloader you presumably have a HEX file? Just program that into the 162 in the same way that you program LED flashers or whatever else. The bootloader HEX file will have an address offset so instead of the code going to 0x0000 like the LED flasher it (hopefully!) goes to 14K so occupies the last 2K of the 162 (actually you may have an issue - does the 162 allow for 2K bootloaders? If not you need to trim the options back to make it build for 1K or less). When you use the USBAsp as well as programming the flash you also need to make a small adjustment to fuses. Activate the BOOTRST fuse and because the bootloader will almost certainly want the biggest bootloader space possible also make sure the BOOTSZ fuses are set to the maximum option.

Now when you apply power the AVR will start to run at the bootloader address (maybe 14K). As long as you have all the SPI wires connected up right then it should be able to read an SD card. Having used srec_cat to convert your LED flasher .hex file to a .bin file (and maybe pogram in a CRC if you are using that bit too) you write that BIN file to an SD card while it's plugged into your PC in a file called something like AVRAP005.bin then when the AVR starts and the bootloader runs it will "see" the file and because there isn't an app present yet it will open and read the file contents and SPM program them into the lower flash area. In future at power on the EEPROM of the AVR will tell it that it already has "005" in memory so it will skip the programming and just jump to the LED flasher at 0. But if you now change the BIN file on the card and now call it AVRAP006.BIN then the bootloader will see that 6 > 5 so it will reprogram and so on.

As I say it keeps the number of the "last programmed" BIN file in EEPROM so it can always tell whether it is up to date. You can erase EEPROM to make it reprogram at next start up.

In your build output this command is wrong:

		"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe" -o pfboot.elf  asmfunc.o main.o mmc.o   -Wl,-Map="pfboot.map" -Wl,--start-group -Wl,-lm  -Wl,--end-group -Wl,--gc-sections -mrelax -Wl,-section-start=.text=0x7000  -mmcu=atmega162 -nostartfiles  
		Finished building target: pfboot.elf

IN the section-start the .text section is being set to 0x7000 which is the right value for a 32K chip that has a 4K boot section (so boot starts at 0x7000) but in a 16K chip with a 2K boot section this should be set to 14K which is 0x3800.

In fact in the command:

$(ProjectDir)Debug\$(TargetName).hex -intel -fill 0xFF 0x0000 0x37FE --l-e-crc16 0x37FE -o AVRAP001.bin -binary

(which is right for 16K) the 0x37FE here is picked because it is 0x3800 (the boundary) minus 2 bytes (because the very last 2 bytes of "application" flash are where the CRC is placed).

So half your setup looks right for 16K and half is wrong.

I think I know where this comes from. I started the SD bootloader on a meag16 which has bootloader sizes of 256 bytes, 512 bytes, 1K and 2K but then the thing just tipped over 2K with all the options switched on. So I moved to a mega32 because it has bootloader sizes of 512 bytes, 1K, 2K and 4K and the last option let me grow things a bit bigger, 32K minus 4K is 28K and 28K happens to be 0x7000 which is where the number in your build came from.

Well in the Project properties it'll be in the "linker" section. I assume I probably put it under "miscellaneous" ?

(having said that the project properties have a "Memories" section. I maybe have put a ".text=0xnnnn" there which ultimately gets converted into a -section-start.

I don't have access to AS7 right now so cannot easily check to see how I did it.

Nope because of the stupid Atmel system ! In that "Memories" section they have some long winded comment which basically says "At Atmel, unlike in the whole of the reset of the universe for flash (but not RAM or EEPROM or anything else) we measure memory in WORDS not BYTES". The upshot of that is that a ".text=0x3800" entered here is converted by them to a -section-start=.text=0x7000 where they double the 0x3800 entered. So by implication to end up with the desired -section-start=.text=0x3800 the value you enter in "memories" will actually half of 0x3800. So try ".text=0x1C00" and in the build you should see it use 0x3800 in the section-start.

(and don't touch -nostartfiles, you MUST have that!)

Actually, now that I look at the text file it looks like your "app" is a copy of the bootloader itself??

I'll say it again. My bootloader does not use Intel Hex files, it uses pure binary files. If yoy have built your app as hex you need to convert it to Bin (binary) for the bootloader to use it. It just does a byte for byte write of the file contents into flash. If that file is Intel hex then that's what will be written to flash and, because it's not AVR code, it won't work.

Yes but as I keep saying the HEX has to be converted to BIN first. From the Project site:

...I then search for the first entry that has the five letters AVRAP at the start. I then make a further assumption that the next 3 characters will be digits and read/convert to binary. This tells me the version number of the app image in the file. I also store a flash image version number in the last two bytes of EEPROM memory so I then compare the two and if the file version is higher than the stored EEPROM version I wipe the EEPROM location back to 0xFFFF (as a marker to say that there is no valid app) then use the "First Cluster" field of the file entry to locate the first cluster of the file.

 

For the entire app section (14K in case of mega16) I then read sectors from that file and in groups of four (sector = 512, SPM page = 128) I program the flash pages in the application section of the AVR. At the end I finally store the new file's version number into EEPROM again to mark the code as being valid.

 

At startup when either no SD is found or any AVRAPP is found to be equal or less than the EEPROM version number I then just try to launch the app. Now at build time for the application I used srec_cat:

 

srec_cat $(MSBuildProjectDirectory)\$(Configuration)\$(Output File Name).hex -intel -fill 0xFF 0x0000 0x37FE --l-e-crc16 0x37FE -o AVRAP001.bin -binary

 

which takes the .hex file, pads all the unused aera wit h0xFF up to the last 2 bytes then it fills those last two bytes with a CRC16 checksum of the entire image. All that wil have been programmed in to the application flash by the bootloader.

You don't HAVE to use srec_cat to make the .hex to .binary conversion if you don't want. The tools that come with avr-gcc already contain avr-objcopy that can simply be used as:

avr-objcopy -I ihex -O binary myapp.hex AVRAP003.BIN

That will simply convert myapp.hex that is in Intel Hex format into AVRAP003.BIN that is in simple binary format. You then copy AVRAP003.BIN (or whatever) to the SD card and insert it. When the bootloader starts up if EEPROM holds 0xFFFF or a number lower than 003 then it will recognise that this is newer code so it will read in the file and program it into the flash.

I did not put Intel Hex decode into the bootloader itself as I was trying to hit a 1K..2K size boundary and an iHex decoder could bloat that but, more than anything, the idea of a bootloader is to be as simple as possible and adding the complexity of iHex decode would have been very likely to introduce bugs (which is fatal in a bootloader that must always work faultlessly). So I leave it to the user to use a PC based tool like srec_cat or avr-objcopy to do the complex iHex to binary conversion before the program code gets anywhere near the SD/MMC card.