Can't see pyboard in DFU mode after firmware update

The official pyboard running MicroPython.
This is the reference design and main target board for MicroPython.
You can buy one at the store.
Target audience: Users with a pyboard.
Post Reply
dsmay4
Posts: 1
Joined: Tue Jul 02, 2019 2:30 am

Can't see pyboard in DFU mode after firmware update

Post by dsmay4 » Tue Jul 02, 2019 2:45 am

Hello! I am brand new and just started playing around with my PyBoard 1.1. I performed a DFU update in accordance with the directions at https://github.com/micropython/micropyt ... are-Update. I performed this in Ubuntu using dfu-util v0.9, and the update process seemed to go smoothly without errors. I reset the device and was able to view the device's filesystem, run code in main.py, as well ad REPL in and run code from there. Unfortunately, the device doesn't show up in DFU mode anymore...

When I execute the command dfu-util -l, I don't see anything show up. I have the recommended /etc/udev/rules.d/49-micropython.rules file.

The command lsusb only shows this with no device descriptor afterwards:

Bus 001 Device 019: ID f055:9800

The board is a v1.1 and I'm pretty sure I uploaded the correct stable version of firmware 1.11. Soft reboot in REPL shows:

MicroPython v1.11 on 2019-05-29; PYBv1.1 with STM32F405RG

I have tried hard resets as well as filesystem resets and fully powering down overnight. Nothing seems to be helping. Any troubleshooting tips would be greatly appreciated.

Thanks,

Dave

User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Can't see pyboard in DFU mode after firmware update

Post by pythoncoder » Tue Jul 02, 2019 5:40 am

The board can exist in two states. In the normal state it provides a REPL and can run programs - it does not show up as a DFU device. The other state is DFU mode where the only thing it can do is perform firmware access (typically uploading a new version).

To upgrade firmware you put it into DFU mode typically by powering up with a link the two pins as described in the doc you referenced. If you do a power cycle or push the reset button without that link it goes into normal mode.
Peter Hinch
Index to my micropython libraries.

User avatar
jimmo
Posts: 2754
Joined: Tue Aug 08, 2017 1:57 am
Location: Sydney, Australia
Contact:

Re: Can't see pyboard in DFU mode after firmware update

Post by jimmo » Tue Jul 02, 2019 5:41 am

Hi,
So you were able to get it into DFU mode once (using a jumper wire to BOOT0 (the DFU pin) ), but since the update this no longer works for you?
Out of curiosity, can you try running "machine.bootloader()" on the REPL and see if that does it?

User avatar
dhylands
Posts: 3821
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: Can't see pyboard in DFU mode after firmware update

Post by dhylands » Tue Jul 02, 2019 5:43 am

You need to connect the DFU pin (aka BOOT0) to 3.3v and press reset to get it in DFU mode, or from the REPL execute pyb.bootloader()

On the pyboard BOOT0 is located right next to a 3.3v pin. If you refer to this photo http://docs.micropython.org/en/latest/p ... ckref.html BOOT0 is in the lower left corner above X17 and to the right of 3V3

User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Can't see pyboard in DFU mode after firmware update

Post by pythoncoder » Tue Jul 02, 2019 5:56 am

My reading of the OP is that he successfully performed a firmware upgrade and is using the board, but is unclear why, when in normal use, the board no longer shows up as a DFU device.
Peter Hinch
Index to my micropython libraries.

smhodge
Posts: 86
Joined: Tue Jan 22, 2019 2:16 am
Location: Kirkland, WA, USA

Re: Can't see pyboard in DFU mode after firmware update

Post by smhodge » Wed Jan 15, 2020 7:20 pm

I'm going to pick up from where this thread left off. I have the same problem, plus others. A few months ago I successfully upgraded the firmware on two 1.1 pyboards to v1.10. I used the DfuSe demo utitilty from ST and did not have any issues. I made notes of exactly how I did it, all of which agrees with what is said in this thread.

But now I am having issues with one of the boards. My code runs fine on it except that it will only TX bytes, not RX them, and this is true of any of 4 UART ports I am using. This is also true not only in my code but in a simple REPL session:

>>> from pyb import UART
>>> sp = UART(6)
>>> sp.init(baudrate=115200)
>>> sp.write('abc') # 'abc' appears on a RealTerm window connected to serial port 6.
3
# Send a byte from the RealTerm window back to the pyboard...
>>> sp.any()
0
>>>

Not only the above issue, but now whenever I open a REPL session it lists the "time epoch" as Jan 1, 2000, and all files that I copy over to the pyboard have that date, and the utility rsync now always copies all files over because they always have a newer date.

Anyway, I wrestled with this for hours, including countless "reset to factory defaults" but to no avail. My code continues to run just fine on the board except for the above serial port RX issue (there may be other issues but so far I haven't encountered any).

I concluded that maybe the fimware on the board has been corrupted, so I tried to repeat the firmware update that I had done without a glitch a few months ago. No go. The DfuSe Demo utility refuses to list the board, despite using as many variations as I can think of (reset the board, open/close the utility, wait for several minutes to find the board, etc). I then tried to use DfuSe Demo on the other pyboard to see if it would work on that (still supposedly good) board but it would not find that board either.

I then tried to install the alternate programmer, dfu-util, which requires the pydfu package, but pip cannot install that (but can install other packages just fine) and I cannot tell from the long list of error messages displayed why it fails. I presume something is wrong with the pydfu package. I am running Windows 10.

So I'm at my wit's end and hope somebody here can help.

Thanks

Post Reply