AVR Freaks

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).

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.

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.

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.

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'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

The 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 

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!

May the Force be with you 

Cheers

Then 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 :)

Hi 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

Adding "someCondition " like that won't solve your problem. 

while(startAddr < endAddr)

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

if((err = usbSetReport(dev, USB_HID_REPORT_TYPE_FEATURE, buffer.bytes, sizeof(buffer.data))) != 0){
                fprintf(stderr, "Error uploading data block: %s\n", usbErrorMessage(err));
                goto errorOccurred;

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

Of 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