Any users of microchips PIC "unified" bootloader?

[Buriedcode]

Hi,

As I'm designing a couple of dev boards for PIC16 and PIC24, I thought I would add provisions for a bootloader - either dedicated button to enter bootloader, or an Arduino-like reset trigger using DTR/RTS.
Rather than one of the older bootloaders I thought I'd give the one built-in to MPLABX MCC - their "unified" bootloader a go.

I added it to the project, configured pins/osc, built the bootloader application, and flashed a micro - the LED indicating "in bootloader mode" is on.

However, using the "Unified Bootlaoder Host Application v1.19.2", with a test blinky hex, and correct serial settings, the console gives:

Code: [Select]

17:53:31.331 > Device: COM7 Bootloading started
17:53:31.408 > Hex File (re)loaded...
17:53:31.409 > (20) Sec Timeout Check per CMD
17:53:31.409 > Reading Version ...
17:53:31.409 > Failure Hint: Check Communication with Device
17:53:31.442 > Transaction Failure: Bootloader Version format not correct


I looked at the data sent between the PC and micro, and it does appear to be the correct format:
Host  > micro:

00 00 00 00 00 00 00 00 00

Micro > host:

E0 55 00 00 00 00 00 00 00 00 00 07 00 00 01 00 00 43 30 00 00 20 20 FF FF FF FF E0 E0

It mentions version, but I have no idea what bootlader version the host app expects - there really isn't much documentation for it.  Given it first says check comms, I can only assume there is some kind of delay between the two?

I'm not sure if micrcohips website is really hard to navigate, or there really isn't much info about the bootlaoder, OR.. I'm just crap at navigating through it, but its a lesson in frustration management.

[Buriedcode]

After almost a day (!) debugging I got it working.

Turns out the FT232R dongle I was using was spitting out extra bytes - specifically 0xFC - often at the start of a packet sent.  I'm not sure if this is due to how Microchips Host app ("UnifiedHost-1.19.2.jar") communicates with it, or if its an FTDI driver issue - note this one uses a chip I bought from Farnell back in 2009 so I very much doubt its a fake that FTDI drivers have screwed with.

I used a CH340 dongle to snoop on the data sent between host (FT232R) and micro (PIC16F1704) and noticed the extra bytes. Always 0xFC.

So, swapping the dongles so the "good" CH340 was used for the bootlaader, got the two talking, but the host would spam the same packet - trying to erase flash but sending '0' for the number of bytes to flash, so the MCU just looped forver.  Out of curiosity I switched to a different host version: UnifiedHost-1.19.0.jar

I couldn't find any release notes about versions on Microchips website, so I have no idea of the differences, but this worked, and pretty much immedaitely flashed a blinky app to the MCU.

Finally (what a saga), there was a bug in the generated bootlader code which didn't read the config words properly, this had to be re-written so it had the correct starting address, and read the high byte as well as the low byte (it just read the memory linearly, addressing words, but only reading out single bytes rather than reading the entire word and splitting it to two bytes).

All this really doesn't inspire confidence in Microchips bootloader - there is one user guide pdf, but thats pretty much it, no other information on their website, and it seems very few people bother using it - at least not for PIC16.  It's got quite a small footprint, so thats nice, I think I'll just write a new host app (C#, .NET, windows only) so that it actually remembers all the address offset settings for different micro's, so I could jsut load a *hex, select the micro to use, and hit send.

[Jon_S]

We looked into using 1.19.1 on a PIC24 product, but wrote our own bootloader in the end.

The changelog is in the readme.txt in the UnifiedHost folder, the latest bits are:

v 1.19.0:   Add LIN support for PIC24/dsPIC devices. Fix issue causing readback errors when only a partial instruction worth of data is specified in the .hex file.
v 1.19.1:   Fix CAN DLL issue with latest USB drivers
v 1.19.2:   Fix MCP2221 DLL issue with latest drivers
v 1.19.3:   Robustness improvements to 16-bit UI implementation when UART driver loading fails.
                Fix issue of CAN BRS setting option being ignored.

Our experience was that it works, but is buggy. One I remember offhand is a error with the range calculation for erase on devices with large amounts of program memory. And there was something about validation that was not correct.

[JPortici]

bah, that thing is overcomplicated for nothing, and goes against their own good practices for 16bit parts (codeguard, AIVT etc)
that one time i looked into using it i ended up writing my own bootloader, because it would have been too difficult to adapt the procotol. I have written several since then, and porting from one family to another is a half a day job.
Bonus: if you change vendors you can keep the code and just change the hardware specific bits (accessing peripherals, writing flash).... Provided you wrote good C to begin with, of course.

you don't really need more commands than
- Check Status
- Erase Flash
- Write Flash (Encrypted or not, up to you. Decrypt on device)
- Verify Image (CRC or what not)
- Optional: Erase/Write EEPROM or other onboard memory.
One thing you don't need is erase/write of configuration words. They should never change between bootloader and firmware.


The API is the same between projects. What may change is the medium:
- UART, it's the basic one. Variable Length frames
- USB, if using bulk endpoints, USB takes care of variable length for me. If using Interrupt (HID) some gymnastics to assemble multiple transactions
- CAN, variable length frames using CAN-TP (which is standard and easy to implement both in firmware and in software, not the bullshit ST and the like came up with)
- LIN, this took a less standard approach but it's simillar to what you would do with UDS over Lin to program an ECU

When i build the firmware i run some scripts after the build
- if the project uses XC8, the bootloader project is added as a loadable. Take the unified hex file, rename, append firmware version, generate the update file
- if the project uses GCC/XC16/XC32, combine hex bootloader file with firmware file using a software i wrote in half a day in standard c++ (or python or what you want), then generate the update file

Because the api is the same across bootloaders and the file format is the same (each bootloader require a different encryption key so i can't accidentaly flash firmwares that don't belong together) i also have a single (or a template) software library for updating everything, and i only have to account for my bugs