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
Can't see pyboard in DFU mode after firmware update
- 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
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.
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.
Index to my micropython libraries.
Re: Can't see pyboard in DFU mode after firmware update
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?
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?
Re: Can't see pyboard in DFU mode after firmware update
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
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
- 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
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.
Index to my micropython libraries.
Re: Can't see pyboard in DFU mode after firmware update
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
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