No I didn't use the ASP set up and my device is already manufactured so changes are out. My device is based from this.
I use a 12 mhz instead but that usb set up is the same. From what I know about usbASP is that its pretty much the same thing (This boot loader is similar to Thomas Fischl's avrusbboot, except that it is built on top of the HID device )but I never worked with it. I think some changes may be needed to make your gui work but that really is nice. I plan to write my own firmware uploader so source code would be invaluable to me. Though again, not sure how USBASP does its bootloader, may be very different. I could not get that 4share to work kept bugging my about fackbook or something?
Does it have a bootloader then? I doubt that. It is is simply an ISP "data pipe". On the PC facing side it looks like a USB device (software simulated) and on the target AVR facing side it is an ISP programmer.
Your device appears to be "stand alone". The bootloader is there so it can program itself, not other AVR so it's nothing like a USBAsp is it (apart from the fact that both happen to use software simulated USB).
Then what is the avrusbboot for? a non avr studio application? anyone can download avr studio and program via isp. Seems like an over kill to me? Also he said he wrote a boatloader. ISP software would write the entire chip right?
Fischl is a very clever bloke. He recognized how useful Objective Development software implementation of USB was.
One project he used it for was USBasp. That (as I say above) uses the USB to interface to a PC then it uses the data channel to deliver data that is immediately programmed on the other side into a second AVR using ISP
A completely separate use for the software-USB he made was to make a standalone program that you can put into the top of an AVR so that it can not only program itself but it can receive the data to achieve that over USB - that project is called avrusbboot.
You see USBAsp and avrusbboot listed as just two of quite a number of projects he has done. In the list there are several using soft-USB. I guess once you have use a great library like that you want to use it in as many different ways as you can think of!
USBasp is arguably the most important 3rd party piece of AVR development electronics/software there is (apart from Arduino). Via ebay I imagine the Chinese have now sold millions and millions of USBAsp to people all over the world who are now able to program their AVR projects with a $2 piece of electronics and a free copy of avrdude.exe. The cheapest offering from Atmel to "get started" has always been around the $50 mark. Sure that $50 thing may give you the luxury of being able to drive it from within Studio but loads of folks are happy to run avrdude separately or, as you can these days, set it up as a "tool" inside Studio so when you execute it, it just feels like it's working "inside" Studio anwyay.
My refer to USBASP is for the schematics only, not the USBASP itself, many of them have use it, so it's easier to start with, without making new hardware.
The point is, it can download the full application firmware size minus 2K bootloader, I believe that's what you're looking for.
S_K_U_N_X wrote:
Though again, not sure how USBASP does its bootloader, may be very different.
Of course it's very different, it's bootloader not ISP programmer.
So USBASP cannot be bootloader except you flash it with bootloader firmware. Then re-program the USBASP firmware in it using bootloader. And you got 2 USB device in a single device.
But that's is useless thing to do with bootloader.
I'm not sure using HID, the bootloader needs how much flash size.
There's BootloaderHID from Christian's with simple GUI. I'm not sure what's your problem with that.
I'm curious to find out making my own HID bootloader using your schematics
S_K_U_N_X wrote:
I could not get that 4share to work kept bugging my about fackbook or something?
.
Not sure with that, any suggestion for other site?
Of course it's very different, it's bootloader not ISP programmer.\
I was never talking about ISP. I said "Though again, not sure how USBASP does its bootloader, may be very different." - meaning different from usbboothid.
I'm not sure what's your problem with that.
This is the entire point to my topic, the issue is that my bootloaders "seems" to be assuming I have a 4k boot. I have a 2k boot. No need to explain that you can read thru all the posts. I didn't really follow much of what you said here but more on point your last comment is what drives my curiosity.
I'm curious to find out making my own HID bootloader using your schematics
This is also what I'm curios about. At home here I was able to get your download. I selected my chip and put in the vid/pid but it was not detected.
Hi, thx for the interest to help me. So this latest zip with the ini. I'm not sure I'm using it right since there is no find button. I put my device in bootloader mode and I put in the vip/pid but it always says no device found. When the right id is put it does it just say found? Or do I have to hit enter or something?
Hi ok I'm following what you are saying a bit better now. At this time I don't wish to try USBbootAVR. I want to stay focused on the bootloader I have and getting this source to compile. If you ever finish what you said here.
I'm still working on the HID bootloader with your schematics, it still in progress. Hope it will finish in few days.
The schematic still using USBASP schematic because I don't want to make the new one.
The purpose of making this is my curiosity making HID device using VUSB.
It's my first try, so I need you to try it to help me find my mistake in it. I hope you don't mind.
Please don't ask for the source code, like another VUSB projects I had shared, I only intended to help people who interested in VUSB, not to do their job.
That is too bad about source, I'd like to use that idea in my code. Would you consider helping me with my code at a later point? I'm not home right now but happy to test later.
or at least that makes more sense to me. But really I should not have any errors....
The endaddr is 28800 minus the bootloader size that's 26752 (6880)hex.
so I'm guessing the size is not the issue here... Looking closer at the error.
when startAddr = 0x07000 and startAddr + (int)sizeof(buffer.data.data) = 0x7080 It throws the comm error.
so I added a print above the error
[buffer.bytes] [sizeof(buffer.data)]
2553172 ..................... 132
if usbSetReport is trowing this error I think the issue is in the bootloader hid code, no? If so my guess would be the usbFunctionWrite section because the set up is done.
nothing stands out? Only a guess here but maybe the usb descriptor is expecting a smaller size chip? Though I do see this comment about timers. /* compatibility with ATMega88 and other new devices: */ So I have to assume the author expects 328's here.
Also I see a few cli's in the bootload code, I wonder if its taking too long and dropping? - doubtful.
interestingly changing to if(endAddr > deviceSize - 1024) didnt change a thing, so I'm sure this it not a size issue. Really confused at this point.
Two more additional points of interest. I tried adding a loop to slow it down and it still failed at the same point. Also if I interrupt the usb transfer I can the same error. The failing at the same point every time is what makes thing confusing. Though this is a clue to what is causing the issue and should be easier to track down and fix as its religiously repeatable.
After doing some research of HIDBoot with 328p (thanks to my curiosity) , here's what I found:
First, I'm not really sure what's going on so I hope someone can explained to me.
Erasing page before writing task...
With page erase function:
boot_page_erase(address.l);
will stuck at address.l = 0x7000 which give error report.
0x7000 is the address of bootloader size 4K.
It's related or not I don't know.
When I use this
boot_page_erase((address.l >> 8) || address.l);
It's working until the last page of 328p which is 0x7780, no error thrown.
My guess is the matter of casting?
Now we are talking about writing the flash...
do{
...
cli();
boot_page_fill(address.l, *(short *)data);
sei();
prevAddr = address.l; <-- here is the problem!
address.l += 2;
data += 2;
...
if(pageAddr == 0){
cli();
boot_page_write(prevAddr); <-- use in here
sei();
...
}while(len);
With above prevAddr setup, "boot_page_write(prevAddr)" will always write to the next page of "boot_page_erase(address.l)".
So erase page 1 but writing at page 2, that's ridicuolus is it?.
Then I moved prevAddr setup right after "boot_page_erase(address.l)".
Now everything goes smoothly.
Here I tried to write 0x81 at entire last page of 328p which at 0x7780 with above setup, and it succeeded. No complain thrown.
Hope someone correct me if I done something wrong.
Ok, I feel like the most stupid people in the world because ignoring datasheet
Ignore my above post about erase and writing at 0x7000 and above it. It was not suppose to happen!
As the datasheet clearly written:
The max rww is 224 pages, which mean 224 * 128 = 28672 bytes !!! Case closed !
So better use 4K bootloader than 2K, same result anyway
After 70 post
BTW, the "prevAddr setup" is still a good progress. Ignoring that will sometimes cause getting garbage data if the application size is changed less than previous size.
And as datasheet said: erase and write at the same page!
But you are wrong. SPM can write to ALL the pages in the device. It's just a question of whether the page data remains readable during the operation. In the first 28K it does not (while sector writes are happening the page reads back as 0xFFs) but in the top section the code remains visible even while the write occurs.
In fact most bootloaders have an address check to ensure that there is not a rogue record in the data or that it is too long so that it might inadvertently write over the bootloader itself.
In fact in the preceding 70 posts the question has been whether the limit being used in such a check has used the wrong boundary.
Hi MicroGyro, thx again for helping... The "bad English" ( as you said) and my limited experience is not helping me follow easily at all. I thinking I have surmised that you are implying using a 4k boot would help me in my case? Your last post implies you're not %100 and you are looking further in to it? In that case may the force be with you ;) i'll remain a padawan for now.
Clawson, what do you make of all of this? I gather your experience to v-usb is only relevant in the preceding 70 posts? Though you have helped me thru so many battle in the last 7 years... Is my confusion shared? Does it make sense to receive a com error because of a hex size? Is the problem still possibly within the bootlaod code and not the v-usb HID data code? I know Christian well enough to say he generally does not make a mistake. Though I have found a pretty significant bug in his firmware only usb code so he is not infallible. :) What confuses things yet a bit further is that the two apps bootloadhid(command line) and boothidflash(gui) produce the same error. But it is very possible the gui was copped from the command tool. In that case it makes sense.
The first 224 pages is RWW section, so using Christian HIDBoot code no problem will exist.
His code sequence doing: "Erase Page" then fill page buffer and after SPM_PAGESIZE achived execute "Write Page".
This sequence don't give error because doing RWW section do not cause CPU halting.
That section is 0 to 0x7000.
The diagram shows better
Now how about NRWW section...
With HIDBoot code, this CPU halt will give error while the CPU doing "Erase Page" task, because HIDBoot code expect return value every 8 bytes data processed by usbfunctionwrite().
With CPU halt, the return value will never return or return USB_Stall thus the code can't continue to do fill buffer and writing flash, so this was how the error start.
What to do then?
The previous sequence not suitable for this 16 pages in NRWW section.
To erase one page, send one set_request, let the CPU halt while doing page erase, don't expect return value.
This can be done for 16 times or one at a time follow by set_request for page write.
According to datasheet doing erase and write causing CPU halt, so erasing and writing this 16 pages needs 32 set_request with ignored return value.
So HIDBoot needs adjustment to cover this. And so the GUI. But if only the NRWW section need.
If not, HIDBoot prety good.
Regarding the HEX size error, I never use debug from Christian. I prefer return the value I suspect using get_request.
So my explaination related to the OP question or not I don't know.
Erase page + (16+1) times loop to fill page buffer + writing page. All of it done in usbfunctionwrite().
16+1 loop got from :
usbfunctionwrite() only process 8 bytes at each call, then give the return value back as the result.
The "Report length" setup in the device is 131 bytes as you can see in HID Descriptor setup (at above part of HIDBoot.c)
So this 131 bytes will be divide by 8 which is 16 times usbfunctionwrite() call + 1 call to process the remaining 3 bytes. 131= 16*8 + 3.
Again: once usbSetReport executed, 131 bytes will transfered to device (which will trigger 16 times usbfunctionwrite() call + 1 extra call for remaining 3 bytes).
Now back to the error part:
As I said when usbSetReport get into address which is at NRWW section(7000~7800), the driver will get into CPU halt condition while "erasing page" at the given address.
above line I wrote:
The 328p device will get into this sequence:
Erase page+ (16+1) times loop to fill page buffer + writing page. All of it done in usbfunctionwrite().
That page will indeed being erase by SPM, but halting condition makes usbfunctionwrite() get into error result.
So usbfunctionwrite() which should be call for 16 times, now only called once because usbfunctionwrite() returns error and all the loop canceled.
That's the reason why at above line of this post I wrote only"erase the page" (in NRWW section). The next sequence after "erase part" won't be executed!
MicroGyro wrote:
What to do then? The previous sequence not suitable for this 16 pages in NRWW section. To erase one page, send one set_request, let the CPU halt while doing page erase, don't expect return value. This can be done for 16 times or one at a time follow by set_request for page write. According to datasheet doing erase and write causing CPU halt, so erasing and writing this 16 pages needs 32 set_request with ignored return value.
Erase page + (16+1) times loop to fill page buffer + writing page. All of it done in usbfunctionwrite(). does not return
this is the solution.
The previous sequence not suitable for this 16 pages in NRWW section.
To erase one page, send one set_request, let the CPU halt while doing page erase, don't expect return value.
This can be done for 16 times or one at a time follow by set_request for page write.
So I loop while(startAddr < endAddr) I need to add a for loop (16 oscillation) ignore return + page write.
I tried this code and it worked, feel like it was too easy. the flash succeeded without err and the code it running. I guess ill make a change in the hex code to verify.
Side effect, takes 16 times as long to flash, but I don't see a way around this because I have to wait for HID to finish. Going to cause many issue for users.
No, my conclusion is that is didn't work. My planted change didn't show up. I think it just flashed over one scion of code, over and over. Still really surprised the device still works. I'll look over it again.
Above code execute 240 pages loops for full flash size;
And inside that each loops you do:
for (i=0;i<16;i++)//do 16 sets ???(step size may need startAddr += (sizeof(buffer.data.data) / 16); usbSetReport(dev, USB_HID_REPORT_TYPE_FEATURE, buffer.bytes, sizeof(buffer.data));startAddr += sizeof(buffer.data.data); usbSetReport(dev, USB_HID_REPORT_TYPE_FEATURE, buffer.bytes, sizeof(buffer.data));//page write
Another 16 loops ?
That means... each loops *16 ? It will takes forever for those 240 pages ! Are you serious ?
You can't just change only your command line code to do this nrww task, because the problem was also inside HIDBoot.c too.
The sequence inside it is always "Page erase + Fillbuffer + Write page".
MicroGyro wrote:
The previous sequence not suitable for this 16 pages in NRWW section.
So that sequence task need to be split up for "Page erase" task and "Fillbuffer + Write page" task while entering nrww section.
I guess you misunderstanding what this "sequence" point to. Sorry for my unclear explanation.
And your command line code changing should follow it.
MicroGyro wrote:
To erase one page, send one set_request, let the CPU halt while doing page erase, don't expect return value. This can be done for 16 times or one at a time follow by set_request for page write.
So with your "planted change", itdo nothing beside erasing nrww section again and again + burning those innocent rww section.
I figured tiring it was the only way for you to explain what I needed to know. This last post did just hat. Since the device is already in production there is no way I can change the HID code. So all hope is lost.
No I didn't use the ASP set up and my device is already manufactured so changes are out. My device is based from this.
I use a 12 mhz instead but that usb set up is the same. From what I know about usbASP is that its pretty much the same thing (This boot loader is similar to Thomas Fischl's avrusbboot, except that it is built on top of the HID device ) but I never worked with it. I think some changes may be needed to make your gui work but that really is nice. I plan to write my own firmware uploader so source code would be invaluable to me. Though again, not sure how USBASP does its bootloader, may be very different. I could not get that 4share to work kept bugging my about fackbook or something?
- Log in or register to post comments
TopDoes it have a bootloader then? I doubt that. It is is simply an ISP "data pipe". On the PC facing side it looks like a USB device (software simulated) and on the target AVR facing side it is an ISP programmer.
Your device appears to be "stand alone". The bootloader is there so it can program itself, not other AVR so it's nothing like a USBAsp is it (apart from the fact that both happen to use software simulated USB).
- Log in or register to post comments
TopThen what is the avrusbboot for? a non avr studio application? anyone can download avr studio and program via isp. Seems like an over kill to me? Also he said he wrote a boatloader. ISP software would write the entire chip right?
- Log in or register to post comments
TopFischl is a very clever bloke. He recognized how useful Objective Development software implementation of USB was.
One project he used it for was USBasp. That (as I say above) uses the USB to interface to a PC then it uses the data channel to deliver data that is immediately programmed on the other side into a second AVR using ISP
A completely separate use for the software-USB he made was to make a standalone program that you can put into the top of an AVR so that it can not only program itself but it can receive the data to achieve that over USB - that project is called avrusbboot.
In fact when you look at:
http://www.fischl.de/projects/
You see USBAsp and avrusbboot listed as just two of quite a number of projects he has done. In the list there are several using soft-USB. I guess once you have use a great library like that you want to use it in as many different ways as you can think of!
USBasp is arguably the most important 3rd party piece of AVR development electronics/software there is (apart from Arduino). Via ebay I imagine the Chinese have now sold millions and millions of USBAsp to people all over the world who are now able to program their AVR projects with a $2 piece of electronics and a free copy of avrdude.exe. The cheapest offering from Atmel to "get started" has always been around the $50 mark. Sure that $50 thing may give you the luxury of being able to drive it from within Studio but loads of folks are happy to run avrdude separately or, as you can these days, set it up as a "tool" inside Studio so when you execute it, it just feels like it's working "inside" Studio anwyay.
- Log in or register to post comments
TopWow, I had no idea, very insightful. So no, this will not work for me as I do plan to use a stand alone HID based bootloader.
- Log in or register to post comments
TopMy refer to USBASP is for the schematics only, not the USBASP itself, many of them have use it, so it's easier to start with, without making new hardware.
The point is, it can download the full application firmware size minus 2K bootloader, I believe that's what you're looking for.
Of course it's very different, it's bootloader not ISP programmer.
So USBASP cannot be bootloader except you flash it with bootloader firmware. Then re-program the USBASP firmware in it using bootloader. And you got 2 USB device in a single device.
But that's is useless thing to do with bootloader.
I'm not sure using HID, the bootloader needs how much flash size.
There's BootloaderHID from Christian's with simple GUI. I'm not sure what's your problem with that.
I'm curious to find out making my own HID bootloader using your schematics
Not sure with that, any suggestion for other site?
I don't know why I'm still doing this hobby
- Log in or register to post comments
TopI was never talking about ISP. I said "Though again, not sure how USBASP does its bootloader, may be very different." - meaning different from usbboothid.
This is the entire point to my topic, the issue is that my bootloaders "seems" to be assuming I have a 4k boot. I have a 2k boot. No need to explain that you can read thru all the posts. I didn't really follow much of what you said here but more on point your last comment is what drives my curiosity.
This is also what I'm curios about. At home here I was able to get your download. I selected my chip and put in the vid/pid but it was not detected.
- Log in or register to post comments
TopI'm sorry, I forgot to include the inf files for windows driver in the zip file, my bad.
I'll fix it as soon as when I get home.
I'm still working on the HID bootloader with your schematics, it still in progress.
Hope it will finish in few days.
But I had to add a boot switch in your schematics to make the device selectable.
And few leds to show the transaction progress.
Cheers
I don't know why I'm still doing this hobby
- Log in or register to post comments
TopHere is the new zip
https://www.4shared.com/zip/u7Dxr5Joei/AVRboot.html
Good luck
I don't know why I'm still doing this hobby
- Log in or register to post comments
TopHi, thx for the interest to help me. So this latest zip with the ini. I'm not sure I'm using it right since there is no find button. I put my device in bootloader mode and I put in the vip/pid but it always says no device found. When the right id is put it does it just say found? Or do I have to hit enter or something?
- Log in or register to post comments
TopHere is the device manager looks like
And the apps after device detected by windows
No need to change VID / PID, it detected automatically and ready to use.
I've been using it for years now and had no problem.
To enter the bootloader mode you have to connect jumper PINC3 to ground then plug in the device. (USBASP speed select)
No need to take off the jumper, if you done with bootloader, unplug the device and remove the jumper.
The device will execute application section when it's powered.
Do not use external supply, use together with USB supply instead, so when you plug / unplug the device it will on/off accordingly.
Good luck
I don't know why I'm still doing this hobby
- Log in or register to post comments
TopHi ok I'm following what you are saying a bit better now. At this time I don't wish to try USBbootAVR. I want to stay focused on the bootloader I have and getting this source to compile. If you ever finish what you said here.
I'd be very interested to try it.
- Log in or register to post comments
TopHere is the app
The schematic still using USBASP schematic because I don't want to make the new one.
The purpose of making this is my curiosity making HID device using VUSB.
It's my first try, so I need you to try it to help me find my mistake in it. I hope you don't mind.
Please don't ask for the source code, like another VUSB projects I had shared, I only intended to help people who interested in VUSB, not to do their job.
Good luck
Here is the zip file
https://www.4shared.com/zip/Qo9ZBIeHca/USBHIDBootAVR.html
I don't know why I'm still doing this hobby
- Log in or register to post comments
TopThat is too bad about source, I'd like to use that idea in my code. Would you consider helping me with my code at a later point? I'm not home right now but happy to test later.
- Log in or register to post comments
Topok so the hid app, there are two issues.
1) no 328 option any longer
2) no way to specify the pid.vid.
I tried anyways no luck.
- Log in or register to post comments
TopThe bootloader hex is for mega 8 (USBASP schematic), you cannot just program it to mega 328, very different size and setting.
And I don't have mega 328 at the moment.
As I said it's my first HID app so I haven't completed the device list and changeable VID/PID yet.
I haven't test it for some other chips either.
Still long way to go. I must buy all the chips and make the board to test. I can only do it when I got spare time and budget.
It's only to test the implementing of VUSB for HID bootloader device, not a real product.
I had provided you two working example above.
It's up to you either you want to try it or not.
May the Force be with you
I don't know why I'm still doing this hobby
- Log in or register to post comments
TopI dont have any mega8 projects or v-usb code around at the moment. Thx for the candor though.
- Log in or register to post comments
TopI know the topic went a bit off here but I'm back on topic. Hope I still have a few watchers out there?
So I have the source compiled and now I see there is some type of issue here. At first look the error thrown is
fprintf(stderr, "Error uploading data block: %s\n", usbErrorMessage(err)); - err says communication error...
but it should be
fprintf(stderr, "Data (%d bytes) exceeds remaining flash size!\n", endAddr);
or at least that makes more sense to me. But really I should not have any errors....
The endaddr is 28800 minus the bootloader size that's 26752 (6880)hex.
so I'm guessing the size is not the issue here... Looking closer at the error.
when startAddr = 0x07000 and startAddr + (int)sizeof(buffer.data.data) = 0x7080 It throws the comm error.
so I added a print above the error
[buffer.bytes] [sizeof(buffer.data)]
2553172 ..................... 132
if usbSetReport is trowing this error I think the issue is in the bootloader hid code, no? If so my guess would be the usbFunctionWrite section because the set up is done.
setup looks like this
while it sends data it will use the write function.
nothing stands out? Only a guess here but maybe the usb descriptor is expecting a smaller size chip? Though I do see this comment about timers. /* compatibility with ATMega88 and other new devices: */ So I have to assume the author expects 328's here.
Also I see a few cli's in the bootload code, I wonder if its taking too long and dropping? - doubtful.
interestingly changing to if(endAddr > deviceSize - 1024) didnt change a thing, so I'm sure this it not a size issue. Really confused at this point.
Two more additional points of interest. I tried adding a loop to slow it down and it still failed at the same point. Also if I interrupt the usb transfer I can the same error. The failing at the same point every time is what makes thing confusing. Though this is a clue to what is causing the issue and should be easier to track down and fix as its religiously repeatable.
- Log in or register to post comments
TopAfter doing some research of HIDBoot with 328p (thanks to my curiosity) , here's what I found:
First, I'm not really sure what's going on so I hope someone can explained to me.
Erasing page before writing task...
With page erase function:
will stuck at address.l = 0x7000 which give error report.
0x7000 is the address of bootloader size 4K.
It's related or not I don't know.
When I use this
It's working until the last page of 328p which is 0x7780, no error thrown.
My guess is the matter of casting?
Now we are talking about writing the flash...
With above prevAddr setup, "boot_page_write(prevAddr)" will always write to the next page of "boot_page_erase(address.l)".
So erase page 1 but writing at page 2, that's ridicuolus is it?.
Then I moved prevAddr setup right after "boot_page_erase(address.l)".
Now everything goes smoothly.
Here I tried to write 0x81 at entire last page of 328p which at 0x7780 with above setup, and it succeeded. No complain thrown.
Hope someone correct me if I done something wrong.
Good luck.
I don't know why I'm still doing this hobby
- Log in or register to post comments
TopOk, I feel like the most stupid people in the world because ignoring datasheet
Ignore my above post about erase and writing at 0x7000 and above it. It was not suppose to happen!
As the datasheet clearly written:
The max rww is 224 pages, which mean 224 * 128 = 28672 bytes !!! Case closed !
So better use 4K bootloader than 2K, same result anyway
After 70 post
BTW, the "prevAddr setup" is still a good progress. Ignoring that will sometimes cause getting garbage data if the application size is changed less than previous size.
And as datasheet said: erase and write at the same page!
May the Force be with you
Cheers
I don't know why I'm still doing this hobby
- Log in or register to post comments
TopBut you are wrong. SPM can write to ALL the pages in the device. It's just a question of whether the page data remains readable during the operation. In the first 28K it does not (while sector writes are happening the page reads back as 0xFFs) but in the top section the code remains visible even while the write occurs.
In fact most bootloaders have an address check to ensure that there is not a rogue record in the data or that it is too long so that it might inadvertently write over the bootloader itself.
In fact in the preceding 70 posts the question has been whether the limit being used in such a check has used the wrong boundary.
- Log in or register to post comments
TopThen I must be misinterpret the question. My bad english.
I'm aware of that. But looking at the datasheet I asume the last 32 pages is not suppose to touch because it is bootloader boundary.
And yet I am wrong. Bootloader can also being updated using SPM.
Have to dig deeper then.
Thank you mr Clawson.
And forgive my bad english :)
I don't know why I'm still doing this hobby
- Log in or register to post comments
TopHi MicroGyro, thx again for helping... The "bad English" ( as you said) and my limited experience is not helping me follow easily at all. I thinking I have surmised that you are implying using a 4k boot would help me in my case? Your last post implies you're not %100 and you are looking further in to it? In that case may the force be with you ;) i'll remain a padawan for now.
Clawson, what do you make of all of this? I gather your experience to v-usb is only relevant in the preceding 70 posts? Though you have helped me thru so many battle in the last 7 years... Is my confusion shared? Does it make sense to receive a com error because of a hex size? Is the problem still possibly within the bootlaod code and not the v-usb HID data code? I know Christian well enough to say he generally does not make a mistake. Though I have found a pretty significant bug in his firmware only usb code so he is not infallible. :) What confuses things yet a bit further is that the two apps bootloadhid(command line) and boothidflash(gui) produce the same error. But it is very possible the gui was copped from the command tool. In that case it makes sense.
- Log in or register to post comments
TopStefan Ernst
- Log in or register to post comments
TopSorry didn't mean to say same error, but both error out based on the same cause. Hex file too big.
Ah very good then.
- Log in or register to post comments
TopHi I'm back
Here is what my conclusion stick to datasheet:
The first 224 pages is RWW section, so using Christian HIDBoot code no problem will exist.
His code sequence doing: "Erase Page" then fill page buffer and after SPM_PAGESIZE achived execute "Write Page".
This sequence don't give error because doing RWW section do not cause CPU halting.
That section is 0 to 0x7000.
The diagram shows better
Now how about NRWW section...
With HIDBoot code, this CPU halt will give error while the CPU doing "Erase Page" task, because HIDBoot code expect return value every 8 bytes data processed by usbfunctionwrite().
With CPU halt, the return value will never return or return USB_Stall thus the code can't continue to do fill buffer and writing flash, so this was how the error start.
What to do then?
The previous sequence not suitable for this 16 pages in NRWW section.
To erase one page, send one set_request, let the CPU halt while doing page erase, don't expect return value.
This can be done for 16 times or one at a time follow by set_request for page write.
According to datasheet doing erase and write causing CPU halt, so erasing and writing this 16 pages needs 32 set_request with ignored return value.
So HIDBoot needs adjustment to cover this. And so the GUI. But if only the NRWW section need.
If not, HIDBoot prety good.
Regarding the HEX size error, I never use debug from Christian. I prefer return the value I suspect using get_request.
So my explaination related to the OP question or not I don't know.
What I spotted is 32K-2K is 30K, not 28K.
224*128 + 16*128 = 30720 bytes.
May the ...
Good luck
I don't know why I'm still doing this hobby
- Log in or register to post comments
TopI'll have to go over this a few times but I think I follow you here.
This is the relevant code
/* Name: main.c
* Project: AVR bootloader HID
* Author: Christian Starkjohann
* Creation Date: 2007-03-19
* Tabsize: 4
* Copyright: (c) 2007 by OBJECTIVE DEVELOPMENT Software GmbH
* License: Proprietary, free under certain conditions. See Documentation.
* This Revision: $Id$
*/
this is the error session that hauls.
If I understand you correctly I need to deny the code sending the error on some condition?
- Log in or register to post comments
TopAdding "someCondition " like that won't solve your problem.
Will executed with no error, but you only "erase the page" (16 pages in NRWW section) not follow by "writing the page" (16 pages in NRWW section).
It will give you 0xFF result inside those pages.
I'll try to give you brief explanation how the VUSB works, hope it helps.
Once this code excecute
The 328p device will get into this sequence:
Erase page + (16+1) times loop to fill page buffer + writing page. All of it done in usbfunctionwrite().
16+1 loop got from :
usbfunctionwrite() only process 8 bytes at each call, then give the return value back as the result.
The "Report length" setup in the device is 131 bytes as you can see in HID Descriptor setup (at above part of HIDBoot.c)
So this 131 bytes will be divide by 8 which is 16 times usbfunctionwrite() call + 1 call to process the remaining 3 bytes. 131= 16*8 + 3.
Again: once usbSetReport executed, 131 bytes will transfered to device (which will trigger 16 times usbfunctionwrite() call + 1 extra call for remaining 3 bytes).
Now back to the error part:
As I said when usbSetReport get into address which is at NRWW section(7000~7800), the driver will get into CPU halt condition while "erasing page" at the given address.
above line I wrote:
The 328p device will get into this sequence:
Erase page + (16+1) times loop to fill page buffer + writing page. All of it done in usbfunctionwrite().
That page will indeed being erase by SPM, but halting condition makes usbfunctionwrite() get into error result.
So usbfunctionwrite() which should be call for 16 times, now only called once because usbfunctionwrite() returns error and all the loop canceled.
That's the reason why at above line of this post I wrote only "erase the page" (in NRWW section). The next sequence after "erase part" won't be executed!
Cheers
I don't know why I'm still doing this hobby
- Log in or register to post comments
TopI feel I have a better understanding now.
This is the issue
Erase page + (16+1) times loop to fill page buffer + writing page. All of it done in usbfunctionwrite(). does not return
this is the solution.
The previous sequence not suitable for this 16 pages in NRWW section.
To erase one page, send one set_request, let the CPU halt while doing page erase, don't expect return value.
This can be done for 16 times or one at a time follow by set_request for page write.
So I loop while(startAddr < endAddr) I need to add a for loop (16 oscillation) ignore return + page write.
I tried this code and it worked, feel like it was too easy. the flash succeeded without err and the code it running. I guess ill make a change in the hex code to verify.
Device size = 32768 (0x8000); 30720 bytes remaining
Uploading 28800 (0x7080) bytes starting at 0 (0x0)
0x07000 ... 0x07080
D:\bootloadHID.2012-12-08\commandline\bootloadhid\Debug>
Side effect, takes 16 times as long to flash, but I don't see a way around this because I have to wait for HID to finish. Going to cause many issue for users.
No, my conclusion is that is didn't work. My planted change didn't show up. I think it just flashed over one scion of code, over and over. Still really surprised the device still works. I'll look over it again.
- Log in or register to post comments
TopOf course it didn't work as expected !
Above code execute 240 pages loops for full flash size;
And inside that each loops you do:
for (i=0;i<16;i++)//do 16 sets ???(step size may need startAddr += (sizeof(buffer.data.data) / 16);
usbSetReport(dev, USB_HID_REPORT_TYPE_FEATURE, buffer.bytes, sizeof(buffer.data));startAddr += sizeof(buffer.data.data);
usbSetReport(dev, USB_HID_REPORT_TYPE_FEATURE, buffer.bytes, sizeof(buffer.data));//page write
Another 16 loops ?
That means... each loops *16 ? It will takes forever for those 240 pages ! Are you serious ?
You can't just change only your command line code to do this nrww task, because the problem was also inside HIDBoot.c too.
The sequence inside it is always "Page erase + Fillbuffer + Write page".
So that sequence task need to be split up for "Page erase" task and "Fillbuffer + Write page" task while entering nrww section.
I guess you misunderstanding what this "sequence" point to.
Sorry for my unclear explanation.
And your command line code changing should follow it.
So with your "planted change", it do nothing beside erasing nrww section again and again + burning those innocent rww section.
Ignore above comment, I just want to scare you
Good luck
I don't know why I'm still doing this hobby
- Log in or register to post comments
TopI figured tiring it was the only way for you to explain what I needed to know. This last post did just hat. Since the device is already in production there is no way I can change the HID code. So all hope is lost.
- Log in or register to post comments
TopPages