Exit from DFU Mode

[danielcbit]

I'm having the same issue.

The update completes successfully using my Mac Pro with macOS Mojave.

sudo dfu-util -D /Users/daniel/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
Deducing device DFU version from functional descriptor length
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!

However my expansion board 3.1 is still in DFU mode no matter what I do.

As other parts of the Pycom documentation, this update steps seem to be half backed. This definitely does not inspire too much confidence in their products. Which is a pity...

[guideon]

@danielcbit Totally agree with you how can we trust Pycom if NO SUPPORT?

[Napfkuchen]

I have the same problem. After updating the expansion board 3.1 with dfu-utils on ubuntu, the board is stuck in DFU mode. I tried to repeat it on Windows 10 and a raspberry pi. Still no luck.

Has somebody found a solution?

Napf

[jimmo]

@guideon @tttadam @danielcbit @Napfkuchen

I have the same issue. I think I've tracked it down to a manufacturing issue with this variant of the board and the bootloader. I was able to make my board work by reprogramming the USB interface chip manually (it's a PIC16F which I've worked with before).

Unfortunately if you don't have a PICKit, I don't see a way to unbreak the board as DFU cannot overwrite the bootloader.

I've written to Pycom with the details, but I suggest you write to them to get a resolution, or return your board to where you bought it and see if you can track down an older revision. Hopefully they'll be able to explain better than my guess!

(Just in case anyone sees this, if you're using Linux and you have the PIC development tools installed (MPLAB) and you're wondering why the expansion board shows up in dmesg as a ttyACM device but /dev/ttyACM0 never appears, it's because Pycom are using Microchip's VID, which the MPLAB udev rules are interfering with).

[tttadam]

@jimmo All right I can write to them, but can we tag them in this thread also?
Are they reading this forum? Probably yes, so they should be avare of this issue.

[jcaron]

@tttadam it’s quite irregular. These last few weeks they don’t seem to have an active presence on the forum at all.

[Andy-ICT2U]

@guideon Has anyone got back to you? I have the same problem (Windows 10 and a v3.1 board) and it's unclear what is needed to get the board back to app mode without having to resort to @jimmo's methods. Anyone from @pycom here?
Can I confirm what I should be seeing?
I have gone through dfu-mode start up and performed the dfu-util-static -D expansion31_0.0.11.dfu which appeared to be successful.
Zadig still reports mode 0xEF99. Tried installing USB Serial (CDC) driver - seemed OK but still reporting 0xEF99.
Anyone got past this?
Cheers
Andy

[noobiemcfoob]

@Andy-ICT2U

I'm also stuck on the same issue using Ubuntu. Sucks too, I'm sitting on 10 expansion v3.1 boards that I can't play with.

[jimmo]

@Andy-ICT2U @noobiemcfoob

Have definitely confirmed (with Pycom) now that the boards are faulty - unfortunately you'll need to get a replacement -- I assume they'll announce something?

The driver that you install with Zadig tells Windows what to do when it detects a given device. Windows doesn't know that 0xef98 and 0xef99 are even the same physical board -- it relies entirely on this identifier (the USB VID/PID) to decide what to do. (I've read a lot of places where people seem to have the mistaken impression that Zadig tells the board what mode to be in, or even that Zadig somehow tells dfu-util where to install the firmware).

On the working boards, the issue that people can run into is that the wrong driver is configured for a given mode, so they try and dfu-util to a device which windows thinks is a CDC ACM serial port, or tell windows that the dfu mode is a serial port.

But in this case, on the 3.1 boards, once dfu-util has been "successfully" run once, it will always boot in DFU mode (PID=0xef99) from that point.

I wrote to pycom again to ask them to update this thread.

[pyoneer]

I have exactly the same problem. Unfortunately, I don't know if it was introduced by the firmware update or already existed before. The first thing I did after receiving the board was to execute the update... If I now check my usb devices (on ubuntu) with lsubs it gives:

Bus 001 Device 070: ID 04d8:ef99 Microchip Technology, Inc. 

The part ef99 indicates firmware update mode as decribed here.
Interestingly, the device doesn't really seem to be in update mode, as trying to execute:
sudo dfu-util -D expansion31_0.0.11.dfu
yields:

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
dfu-util: Cannot open DFU device 04d8:ef99
dfu-util: No DFU capable USB device available

To perform a proper firmware update I still have to press and hold the S1 button while connecting the Expansion Board.

Hopefuly Pycom is working on a solution ...

[frecfrec]

This post is deleted!