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
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.elfIN 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
TopPages