Posted by JohanEkdahl: Tue. Jun 6, 2017 - 08:29 PM
1
2
3
4
5
Total votes: 0
Or click "releases" on the left and get the source as a zip.
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]
A couple of hours of headache and I managed to download the files.
You could simply give a direct link to the zip archive
Without the use of SVN project menage
This would save a million nerve cells and time to many people.
I hope for half a year to figure out how this works, compile and run on my knee
Posted by JohanEkdahl: Sat. Jun 10, 2017 - 12:43 PM
1
2
3
4
5
Total votes: 0
> You could simply give a direct link to the zip archive
And then assume that the zip is the preferred variant? For some, SVN might be preferred.
And the ZIP is a release. What if someone wanted the current development version? What if someone wants to see the history? Etc.
Also, linking to the ZIPwould have ppl "land" on a page with no description whatsoever - don't you think it's better to land at the main page (with the description) and then have a choice of your own on where to go?
How hard was it to browse through the page and see what might lead to sources?
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]
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.
First of all, I hope that this thread is not dead and that you are still watching this ...
I have read all comments, as well as your project page. So I understand how it all fits together and what needs to be changed if you want to implement it yourself.
But since this is my first bootloader, I'm a bit stuck about how to program it.
I try to use an ATmega162, as far as I know it should also be able to work?
I also have a USBasp programmer and I have Arduino IDE as well as AS7. I managed to program a simple program (blinking led) via both programs, in AS7 by using avrdude so I do not know how srec_cat works.
I also managed to build to bootloader, but now I'm kinda stuck... Can you explain to me step by step how I program this bootloader? (Preferably in 1 of these programs)
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.
I think I understand what you're saying, only I do not know if I'm doing that BOOTRST and SZ correctly.
But to answer your concern if the 162 allows a 2K bootloader;
Datasheet quote:
When the BOOTRST Fuse is unprogrammed, the boot section size set to 2K bytes and the IVSEL bit in the GICR Register is set before any interrupts are enabled, the most typical and general program setup for the Reset and Interrupt Vector Addresses is...
So I guess it does?
Between my previous post and now I have managed to get a bit further, please correct me if I did something wrong.
- Firwmare to BIN: I used to argument below to do this.
This argument is based on information from this site and the fuses are set for a 8MHz internal clock. I think I'm not doing anything with those BOOTRST and SZ fuses? Do I need to implement these here?
The argument seems to work, beyond the fact I get an error in the output file (see "BL output")
avrdude.exe: ERROR: address 0x7010 out of range at line 1 of C:\Users\gijsv\Desktop\Masterproef\Software\Bootloader\trunk\Debug\pfboot.hex
According to my calculation, this results in a file of 28 688 Bytes... WHAT????
So I'm pretty sure something is wrong somewhere... Then I went to check the size of pfboot.hex. I have been able to reduce this to 4.31KB by removing all superfluous code and comments.
So euhmm yeah... What's up with that? A bad argument? Or missing a setting somewhere?
I checked the optimization level it's optimized for size.
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.
(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!)
Okay so I did some changes and the LED isn't flashing anymore... now it's constantly on.
What does this mean? Can't find any information about that, so I assume something is wrong or that it's stuck on something?
FYI: My firmware I'm trying to upload is a LED flashing on another pin.
If I take out the SD, it goes back to flashing. So that part still works.
Okay so I enabled UART (had to disable ROOT_MULTISEC for that).
This way I figured out that the LED is constantly on while the µC is "reading" the SD.
When I now look at the data coming from the UART I can see that the CRC isn't eaqual at the end.
Quote:
App CRC= 1117
Flash CRC= FFFF
Could you help me out with this?
Earlier in the data I see the file name (line 123), so the µC seems to find the file. But what seems strange to me is a few lines earlier (lines 99-104):
I don't know if I have to worry about that and if that's causing the problem?
Anyway I'm using a 4GB SD, formatted in FAT32 with 16KB clusters. Tried 32KB clusters and FAT16 with 16KB (by reducing the size to 1GB), both having the same result.
If the CRC is wrong it sounds like the srec_cat command may be wrong. Try switching off CRC support for now to simplify things.
.
Your UART output shows the data being read from sectors and programmed so does your actual application contain SD reading code too. Those messages about disk error look like something in your own code in AVRAP001. BIN
Dear clawson T.U and yes, this is about your perfect bootloader. please help me. i have a hardware and programed atmega32 by your bootloader (with options : 32 bit fat support and uart debuging) and hex file of sample app . my programer is atmel ice . If I want to use crc option too then guide me further. i'm new about MC.
And a question : Does res=0001 mean that the MMC is Initialized ? T.U again.
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:
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:
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.
Or click "releases" on the left and get the source as a zip.
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]
- Log in or register to post comments
TopThank's
A couple of hours of headache and I managed to download the files.
You could simply give a direct link to the zip archive
Without the use of SVN project menage
This would save a million nerve cells and time to many people.
I hope for half a year to figure out how this works, compile and run on my knee
- Log in or register to post comments
Top> You could simply give a direct link to the zip archive
And then assume that the zip is the preferred variant? For some, SVN might be preferred.
And the ZIP is a release. What if someone wanted the current development version? What if someone wants to see the history? Etc.
Also, linking to the ZIPwould have ppl "land" on a page with no description whatsoever - don't you think it's better to land at the main page (with the description) and then have a choice of your own on where to go?
How hard was it to browse through the page and see what might lead to sources?
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]
- Log in or register to post comments
TopTo 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.
- Log in or register to post comments
TopDear Cliff aka clawson,
First of all, I hope that this thread is not dead and that you are still watching this ...
I have read all comments, as well as your project page. So I understand how it all fits together and what needs to be changed if you want to implement it yourself.
But since this is my first bootloader, I'm a bit stuck about how to program it.
I try to use an ATmega162, as far as I know it should also be able to work?
I also have a USBasp programmer and I have Arduino IDE as well as AS7. I managed to program a simple program (blinking led) via both programs, in AS7 by using avrdude so I do not know how srec_cat works.
I also managed to build to bootloader, but now I'm kinda stuck... Can you explain to me step by step how I program this bootloader? (Preferably in 1 of these programs)
Kind regards,
Gijs
- Log in or register to post comments
TopWell 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.
- Log in or register to post comments
TopThanks for your answer, clawson.
I think I understand what you're saying, only I do not know if I'm doing that BOOTRST and SZ correctly.
But to answer your concern if the 162 allows a 2K bootloader;
Datasheet quote:
So I guess it does?
Between my previous post and now I have managed to get a bit further, please correct me if I did something wrong.
- Firwmare to BIN: I used to argument below to do this.
- Then I managed to build the bootloader and tried to program it. I'll put the outputs as attachments.
As you can see in "Build output" it does build correctly and has a size of 1514 bytes, which corresponds to your specifications.
So next I tried to program it using the USBasp and the argument below.
This argument is based on information from this site and the fuses are set for a 8MHz internal clock. I think I'm not doing anything with those BOOTRST and SZ fuses? Do I need to implement these here?
The argument seems to work, beyond the fact I get an error in the output file (see "BL output")
According to my calculation, this results in a file of 28 688 Bytes... WHAT????
So I'm pretty sure something is wrong somewhere... Then I went to check the size of pfboot.hex. I have been able to reduce this to 4.31KB by removing all superfluous code and comments.
So euhmm yeah... What's up with that? A bad argument? Or missing a setting somewhere?
I checked the optimization level it's optimized for size.
Attachment(s):
- Log in or register to post comments
TopIn 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:
(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.
- Log in or register to post comments
TopOkay, thanks for your reply!
I see what you're talking about, but how do I change it?
I do not seem to find wher that valui is being set...
- Log in or register to post comments
TopWell 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.
- Log in or register to post comments
TopFortunately enough I do ;)
In miscellaneous it says: "-nostartfiles"
In memory it says: ".text=0x3800"
So euhmmm? This should be correct, right?
- Log in or register to post comments
TopNope 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!)
- Log in or register to post comments
TopOh yeah didn't read that far down..
But yeah that did the trick, now after building it gives the 0x3800.
So I'm going to try and program it and will get back to you.
- Log in or register to post comments
Topthe word (16bit) comes because the AVR103(mega128) have more than 64Kbytes, so it was the easy way/hack to keep addr. to 4 digit hex.
- Log in or register to post comments
TopThanks a lot for your help clawson, I was able to program the bootloader successful.
Unfortunately, I get the flashing LED. So time for some debugging I guess... :)
Btw the BIN argument was correct, right?
- Log in or register to post comments
TopOkay so I did some changes and the LED isn't flashing anymore... now it's constantly on.
What does this mean? Can't find any information about that, so I assume something is wrong or that it's stuck on something?
FYI: My firmware I'm trying to upload is a LED flashing on another pin.
If I take out the SD, it goes back to flashing. So that part still works.
- Log in or register to post comments
TopI've actually forgotten! Suggest you read the source to see what it is I do with LED.
- Log in or register to post comments
TopHi Clawson,
Okay so I enabled UART (had to disable ROOT_MULTISEC for that).
This way I figured out that the LED is constantly on while the µC is "reading" the SD.
When I now look at the data coming from the UART I can see that the CRC isn't eaqual at the end.
Quote:
Could you help me out with this?
Earlier in the data I see the file name (line 123), so the µC seems to find the file. But what seems strange to me is a few lines earlier (lines 99-104):
Quote:
I don't know if I have to worry about that and if that's causing the problem?
Anyway I'm using a 4GB SD, formatted in FAT32 with 16KB clusters. Tried 32KB clusters and FAT16 with 16KB (by reducing the size to 1GB), both having the same result.
I appreciate all help!
Attachment(s):
- Log in or register to post comments
TopIf the CRC is wrong it sounds like the srec_cat command may be wrong. Try switching off CRC support for now to simplify things.
.
Your UART output shows the data being read from sectors and programmed so does your actual application contain SD reading code too. Those messages about disk error look like something in your own code in AVRAP001. BIN
- Log in or register to post comments
TopActually, now that I look at the text file it looks like your "app" is a copy of the bootloader itself??
- Log in or register to post comments
TopNo, my own code is a simple blinking LED.
Tested it before putting it on the SD and does work.
- Log in or register to post comments
TopSo, I disabled CRC support.
But the only difference I'm seeing is that the flashver is changing. So it does know the version from the app, but isn't running it.
Is it possibele it is either not leaving the bootloader or either doing a faulty programming?
My app itself is working correctly when I'm programming it's hex file directly.
- Log in or register to post comments
Tophi
I made it but just flashes it and the message uart is : B/L start res=0001
I checked all the connections to the card and used the 32-bit and 16-bit memory card, and of course the Hex format file. What's the problem?
- Log in or register to post comments
Top- Log in or register to post comments
TopDear clawson T.U and yes, this is about your perfect bootloader. please help me. i have a hardware and programed atmega32 by your bootloader (with options : 32 bit fat support and uart debuging) and hex file of sample app . my programer is atmel ice . If I want to use crc option too then guide me further. i'm new about MC.
And a question : Does res=0001 mean that the MMC is Initialized ? T.U again.
- Log in or register to post comments
TopI'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.
- Log in or register to post comments
TopCan I use your bootloader mmc library to program the hex file?
- Log in or register to post comments
TopYes but as I keep saying the HEX has to be converted to BIN first. From the Project site:
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:
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.
- Log in or register to post comments
TopPages