just getting back from LMCC smart challenge and the USb for the Expansion 3 keeps ‘flapping’.
When I can see the VID/PID in Device Manger (Windows 10) it is 0x04D8/0xEF99, indicating that it’s in DFU mode not Application mode.
(reference pycom firmware docs )
But I have not/am not pressing the ‘safe boot’ button. ?
Any thoughts?
Hi Dave,
It sounds like DFU is installed on both modes (bootloader and application). I’d start with updating the application-mode firmware, the steps are listed under the title:
Double-check Serial USB (CDC) driver is installed in Application mode
https://docs.pycom.io/pytrackpysense/installation/firmware
When fixed, you’ll see the USB Product ID 0xEF98 when in application mode, along with the correct listing in the device manager (for Windows computers)
Thanks Graham, all good now.
Also noted that S1 is the button to put in DFU mode.
Glad to hear you’re back on track!
I’m seeing what sounds like the same issue. I wrote to pycom last week but no reply.
$ dfu-util -D ~/downloads/expansion31_0.0.11.dfu
dfu-util 0.9
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
Match vendor ID from file: 04d8
Match product ID from file: ef99
Opening DFU capable USB device...
ID 04d8:ef99
Run-time device DFU version 0100
Claiming USB DFU Runtime Interface...
Determining device status: state = dfuIDLE, status = 0
dfu-util: WARNING: Runtime device already in DFU state ?!?
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0100
Device returned transfer size 64
Copying data from PC to DFU device
Download [=========================] 100% 16384 bytes
Download done.
state(2) = dfuIDLE, status(0) = No error condition is present
Done!
After flashing, the board just comes back in DFU mode. Not holding down S1.
Same on Linux and Mac. I use dfu-util all the time with other boards with no problems.
Any ideas? Thanks
jimmo
I think you have to follow the second part of the process in the link.
For some reason the board seems to put the DFU code in the application memory space. You have to force it to use the ‘User Serial CDC’ driver. In Windows you can use Zadig, on Linux I think there’d be a table of device IDs and the relevant drivers.
What’s ‘lsusb’ say in application mode?
P.S. I gave mine back to Graham and he fixed it, so I’m not 100% on the process.
Dave
Thanks Dave,
Sounds like things are a lot more complicated on Windows, the thing that Zadiag does isn’t really applicable on Linux.
It always shows the DFU vid/pid (04d8:ef99) in lsusb, i.e. it’s always running the DFU bootloader. (And like your first message, it flaps every seven seconds).
If there was something wrong with the flashing process, then it would just crash or reset loop as the bootloader (without S1 held down) tried to jump to the main code. But the fact that it’s staying in the bootloader makes me wonder if there’s some check to see whether there’s valid code flashed, and whatever is in expansion31_0.0.11.dfu isn’t passing this check.
Jim
I’m yet to see a Pycom board that was not recoverable when the DFU was written to application mode instead of bootloader mode. With that said, it is a process-puzzle. Bear with it.
Hi Graham,
Sorry I don’t understand what you mean by “DFU was written to application mode instead of bootloader mode”. Any ideas what I’m doing wrong? The DFU file itself contains the flash offsets to write at.
Thanks
There are two modes, application mode and bootloader mode. The symptom you’ve described is what happens when the DFU has been uploaded to both.
You’ll need to restore application mode, as described in the docs. I’d leave it at that, because there’s not a lot to gain out of updating the DFU on the expansion boards. Just update the dev board firmware (LoPy4 or otherwise) using the much-easier-to-use Pycom Update Tool (downloadable on this page).
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?
Great intel, thanks for sharing.
I haven’t run into that issue, and it sounds like we have a similar environment (I use the PICKit for all sorts of stuff).
Pydocs is open source, so you could do a pull request to modify the instructions. Though it might be worth considering if the origin issue is repeatable before doing so.
There’s no special support-swim lane with Pycom, given you’ve already got an interaction in work with them, it would be best to follow that way (if you can spare the time).
For future readers; I’d recommend not updating the Expansion Board unless it’s mission critical. Stick with updating the Pycom dev-board (LoPy4, WyPy, etc) using the much easier firmware tool that I linked above
I’ve just encountered this again, so a bit more information.
The LoPy+Expansion 3 had been sitting around for a while with a Lithium Battery plugged in. Battery was FLAT. I seem to remember the last time the issue occurred after leaving the battery connected.
Windows did it’s usual thing, ‘flaping’ around seeing both PIDs. Device Manager and Zadig were both un-usable.
I put the Expansion into DFU mode (hold S1 while powering up), used ‘dfu-util -D expansion3_0.0.9.dfu’, the board stabilized and Windows found the CDC driver.
This suggests to me that the LoPy was in some sort of boot loop where it didn’t actually get into Application Mode properly.
Hard to say without knowing the way the device has been used overtime and what experiments have been done with it.
I don’t recommend having a LiPo connected for any firmware related experimenting.
No problem Graham, just thought it may help others to know the LoPy can get into this state by leaving the battery connected and going flat.
Dave
Interesting. All of our community mappers have the same setup and they often go flat. I haven’t seen that happen before though I’ll keep my eyes peeled
And you can get our latest projects and tips straight away by following us on:
