Potential Bug
Potential Bug
I found an issue with the PyBoard running MicroPython V1.x.
Enter the following code in REPL.
from pyb import Pin
PB3 = Pin("B3", Pin.IN)
PB3.value() #reports 1
Now if you press the USR button and release it, then issue a Ctrl-D at the terminal, the board will go into a fault state with LED's blinking and hangs.
Curiously, if you eliminate the "Pin.IN" mode in the code above, it doesn't behave this way.
I found a work-around by setting the commenting out the #defines in the config.h file for the USR pushbutton.
Enter the following code in REPL.
from pyb import Pin
PB3 = Pin("B3", Pin.IN)
PB3.value() #reports 1
Now if you press the USR button and release it, then issue a Ctrl-D at the terminal, the board will go into a fault state with LED's blinking and hangs.
Curiously, if you eliminate the "Pin.IN" mode in the code above, it doesn't behave this way.
I found a work-around by setting the commenting out the #defines in the config.h file for the USR pushbutton.
Re: Potential Bug
I don't see that behavior. My Control-D behaves exactly as expected.
Do you have any other software running?
Presumably something else must have been modified since I had to do: (i.e. use pyb.Pin rather than just Pin).
I tested with both of these versions:
Do you have any other software running?
Presumably something else must have been modified since I had to do:
Code: Select all
>>> PB3 = pyb.Pin('B3', pyb.Pin.IN)
>>> PB3.value()
1
>>>
I tested with both of these versions:
Code: Select all
MicroPython v1.12-664-gba5349c94-dirty on 2020-08-12; PYBv1.1 with STM32F405RG
MicroPython v1.13-68-g42342fa3c on 2020-09-18; PYBv1.1 with STM32F405RG
Re: Potential Bug
Try it exactly as I mentioned.
I tried it on both V1.1 and V1.3.
Be sure to press the USR button afterwards. Then press Ctrl-D.
I tried it on both V1.1 and V1.3.
Be sure to press the USR button afterwards. Then press Ctrl-D.
Re: Potential Bug
Hi,
v1.1 and v1.3 are both very old versions.
Could you please confirm exactly which versions you're using? Like dhylands' example, when you hit Ctrl-D normally it will print out the exact version string before the REPL starts. (Or hit Ctrl-B to just show the banner).
Also, which pyboard are you using? PYBv1.0, PYBv1.1, or PYBD.
Thanks!
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Re: Potential Bug
I can't replicate this on a Pyboard 1.1 or on a Pyboard D SF2W.
Peter Hinch
Index to my micropython libraries.
Index to my micropython libraries.
Re: Potential Bug
It seems to be an issue with V1.10. Using PyBoard V11.
V1.3 doesn't have this issue, as far as I can tell.
MicroPython v1.10-227-g696549d2e on 2019-03-16; PYBv1.1 with STM32F405RG
Type "help()" for more information.
>>>
paste mode; Ctrl-C to cancel, Ctrl-D to finish
=== from pyb import Pin
=== PB3 = Pin("B3", Pin.IN)
=== PB3.value() #reports 1
1
>>> Now I type Ctrl-D and board responds with the following and locks up for several minutes.
MPY: sync filesystems
MPY: soft reboot
V1.3 doesn't have this issue, as far as I can tell.
MicroPython v1.10-227-g696549d2e on 2019-03-16; PYBv1.1 with STM32F405RG
Type "help()" for more information.
>>>
paste mode; Ctrl-C to cancel, Ctrl-D to finish
=== from pyb import Pin
=== PB3 = Pin("B3", Pin.IN)
=== PB3.value() #reports 1
1
>>> Now I type Ctrl-D and board responds with the following and locks up for several minutes.
MPY: sync filesystems
MPY: soft reboot
Re: Potential Bug
Under 1.13 I see no appreciable delay. I seem to recall that I may have small delays (around 3 seconds - most likely filesystem related).
I downloaded the v1.10 firmware from here: https://micropython.org/resources/firmw ... -v1.10.dfu and also didn't have any issues (I had to reset my filesystem since the boot.py was from a newer version of micropython and the pyb.country call didn't exist in 1.10)
Perhaps you should try doing a filesystem factory reset: http://docs.micropython.org/en/latest/w ... filesystem (this will wipe any files on the filesystem)
Code: Select all
MicroPython v1.13-68-g42342fa3c on 2020-09-18; PYBv1.1 with STM32F405RG
Type "help()" for more information.
>>>
>>> from pyb import Pin
>>> PB3 = Pin("B3", Pin.IN)
>>> PB3.value()
1
>>> # I pressed and released the USR switch here
>>>
MPY: sync filesystems
MPY: soft reboot
MicroPython v1.13-68-g42342fa3c on 2020-09-18; PYBv1.1 with STM32F405RG
Type "help()" for more information.
>>>
Code: Select all
MicroPython v1.10 on 2019-01-25; PYBv1.1 with STM32F405RG
Type "help()" for more information.
>>>
>>> from pyb import Pin
>>> PB3 = Pin("B3", Pin.IN)
>>> PB3.value()
1
>>> # I pressed and released the USR switch here
>>>
PYB: sync filesystems
PYB: soft reboot
MicroPython v1.10 on 2019-01-25; PYBv1.1 with STM32F405RG
Type "help()" for more information.
>>>
Re: Potential Bug
os.mkfs is not recognized with PYB version. Seems mkfs is not a method contained in os. It's for WiPy according to the link you referenced.
I had tried another PYB with V1.13 and it failed as above. I tried both DFU Util in Ubuntu 18 Linux (in VMware) and ST DFU programmer in Windows 10.
Also, this is a clone PYB from China which appears to be identical except it has an extra BOOT mode button. I've purchased about 10 of them and they all seem to function as expected. Quality is good.
https://www.banggood.com/Pyboard-MicroP ... rehouse=CN
Formatting and/or checking the PYB drive had no effect.
the issue seems to be the version I downloaded "pybv11-20200902-v1.13.dfu"
If I program the board with a version I built from the latest repo, file name is in ../build-PYBV11/firmware.dfu and IT DOES NOT exhibit the problem. So something is wrong with the DFU file I downloaded?
I've checked this along with an associate and we both came to the same conclusion.
I had tried another PYB with V1.13 and it failed as above. I tried both DFU Util in Ubuntu 18 Linux (in VMware) and ST DFU programmer in Windows 10.
Also, this is a clone PYB from China which appears to be identical except it has an extra BOOT mode button. I've purchased about 10 of them and they all seem to function as expected. Quality is good.
https://www.banggood.com/Pyboard-MicroP ... rehouse=CN
Formatting and/or checking the PYB drive had no effect.
the issue seems to be the version I downloaded "pybv11-20200902-v1.13.dfu"
If I program the board with a version I built from the latest repo, file name is in ../build-PYBV11/firmware.dfu and IT DOES NOT exhibit the problem. So something is wrong with the DFU file I downloaded?
I've checked this along with an associate and we both came to the same conclusion.
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Re: Potential Bug
In which case I'd check the electrical connection of that particular pin. I suspect a hardware problem.this is a clone PYB from China
It's not really possible for us to support clone boards unless someone happens to own that hardware. I suggest you buy a genuine Pyboard and test that. If you can replicate the fault on a genuine board then we can help you to isolate the fault.
Peter Hinch
Index to my micropython libraries.
Index to my micropython libraries.
Re: Potential Bug
Same thing happened to my custom board which replicated the Pyboard. So I kind of doubt it's a connector issue. Besides, the clone board has been working perfectly since I built my own 1.13 kernel.