I have a few UBW's I've boxed up all nice and I'd like to flash the firmware without needing to open them up and press the two little buttons (in that delightful fashion which I can now do suspended upside down and blindfolded). I think a 'BL' command to enter bootloader mode would be hot.

I started by downloading the source for the bootloader and attempting to motify it. Unforunately, I couldn't even get it to compile!

My next plan was to simply use an "_asm goto" from within FW_D to jump to the vector where the bootloader starts doing its thang. Unforunately, I couldn't get my PICkit 2 to work in debugging mode so my hands are tied as far as determining that vector.

Sweet. Yup, I've wanted that for awhile. I included exactly that command in the UBW32 firmware.

The trick is that you need to modify both the bootloader and the firmware. The bootloader needs to have another way to get into 'bootloader' mode. So on the UBW32 I used a special fixed location in ram, and from the firmware I put a special key there. When the bootloader gets control, it checks for the presence of this key (since RAM is not lost when you reset with power applied) and then goes into bootloader mode. I did not have space with the original UBW bootloader to add this feature.

Have you tried the latest .zip file for the bootloader project that I just posted last night? That compiled for me no problem.

This is a great feature to add, and if you're able to get it to work, I'd be happy to put it into the UBW firmware and bootloader. I won't have time for a couple weeks (vacation) but I could work on it later this month if you don't get to it before I do.

When you're in the bootloader changing the code, the other thing I've wanted to add (and I did add to the UBW32 bootloader) is 'erased flash detection'. That is, upon boot, the bootloader will check to see if the rest of flash is in an erased state, and if so, it will go into bootloader mode. This means that as soon as you reset after programming the bootloader into the UBW, it will go right into bootloader mode and not try to run the non-existent firmware.

So there should be 3 ways to get into bootloader mode when the bootloader boots:

1) PRG button held down
2) Special key in RAM present
3) Flash is in erased state

I didn't even know about the latest .zip. Great timing, sir! I just downloaded it and it compiles fine. I don't have time to work on it at the moment, but I will certainly update you soon with my progress.

I believe those are the most recent for UBW32. The HIDBootloader files you point to should include all of the features mentioned above. (Note that the 'new' bootloader I spoke of in the previous posts in this thread were for UBW, not UBW32, and were not HID based.)

OK, so one thing to note - there is a lot of history here. Both the UBW and UBW32 bootloader pre-dates AN1388, and not only that, AN1388 has gone through several versions. Agrh. Thank you Microchip. It would have been FAR better for people like us if you had just created a bootloader protocol, named it, stuck to it, and if need be, created another one WITH A DIFFERENT NAME and continued supporting the old and the new. But alas, it was not to be.

So to be completely honest, I'm not sure how much the UBW32 bootloader follows what is currently in AN1388. After speaking with Microchip on this subject for a professional project a couple weeks ago, it was told to me that the latest AN1388's code is better than the 'old' bootloader that came as part of MAL (now called MLA - again, can we stick with one name please?). But that was in reference to the Mass Storage USB bootloader, not the HID bootloader. Although some of the comments regarding the AN 1388 are still probably quite applicable. For example, AN1388 is quite a bit more optimized than the general USB stack that the old HID bootloader is based on. For example, AN1388 now has just the bare minimum USB code (which is now separate from MLA USB stack) stripped down for size. It is also compiled in MIPS16 mode to save space. Etc.

So, none of the above really answers your question. But I wanted to set the stage for everybody - these things are not static, and it's always more complicated than you think it should be going in. Just a warning.

In the current (as of 10/16/2012) UBW32 HID bootloader, when we first boot up, we check for the PRG switch held down or a valid SoftwareKey (the value 0x12345678 at RAM address 0xA0000000). The second allows you to always force the bootloader to run programmatically from your application if you want. (just set the SoftwareKey value, then reset the processor, making sure to shut down the USB SIE first.) Now, if neither of those two things are present (PRG switch pressed or valid SoftwareKey) then we try to boot the application (jump to the reset vector). But first, we check to see if it's erased - i.e. 0xFFFFFFF. If it is, then we don't jump to it but rather enter bootload mode.

The reset vector for the application is at address 0x9D006000.

So if you erase the block that starts at 0x9D006000, you will always enter bootload mode when you next reset. Note that you can also do this same thing non-destructively with the SoftwareKey if you want.

To erase a block of flash you can use the PLIB flash functions. That's what we do in the bootloader.