Sorry, that’s just not how DFU works. I think that Windows is confusing the issue with whatever you have to do to register the right driver for the right USB VID:PID. As you can see in the dfu-util output above, I’m writing to:
ID 04d8:ef99 (which is the VID:PID used by the bootloader).
The .dfu file just says “put these bytes at these addresses”. The bootloader is the first 0x200 bytes, the application is the rest. If you look at the .dfu file you’ll see the first 0x200 bytes are empty. The bootloader knows how to receive commands from dfu-util to write bytes to flash. It has no concept of “uploading to the wrong mode”. In fact, it cannot write to it’s own flash. The bootloader checks if S1 is held down, if not it verifies that valid code is written the application flash, and jumps to that. If the application flash has an invalid checksum (or, see below) is blank, then it reboots.
I wasn’t getting anywhere with Pycom support so I dug into this a bit further. Long story short, it appears that this particular revision of the expansion board has a older revision of the PIC16F1459 that has a silicon bug with flash programming (i.e. this means that the bootloader will just erase flash when it tries to program).
The errata says that there’s a workaround, but the code that their bootloader is likely based from seems less optimistic. (Edit: the workaround is to drop the internal oscillator to <= 4MHz, but there’s no way to run the USB in that case).
I made a firmware image manually from the .dfu file, and flashed it manually using my PICKit. Now the board is working.
My board has 1908 in the bottom right corner of the PCB and the PIC’s manufacturing code is 904YDC. So if you have this board…probably best don’t try and use dfu-util or update the firmware. Otherwise, I think this is only recoverable with a PICKit.
@Graham are you able to contact your supplier and see if they can verify this with Pycom. Given that you can’t DFU the bootloader, I don’t see a workaround other than replacing the boards?
Also, just in case someone on Linux sees this – the pycom firmware uses Microchip’s USB VID (0x04d8) for both the bootloader and the application mode. No big deal for the bootloader, but if you also happen to have the PIC dev tools installed (MPLAB), then the udev rules will get confused and prevent the ttyACM device from showing up. This will be true for all Pycom boards I think?