Page 1 of 1
Potential Bug
Posted: Fri Sep 18, 2020 9:32 pm
by bradstew
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.
Re: Potential Bug
Posted: Fri Sep 18, 2020 11:25 pm
by dhylands
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:
Code: Select all
>>> PB3 = pyb.Pin('B3', pyb.Pin.IN)
>>> PB3.value()
1
>>>
(i.e. use pyb.Pin rather than just Pin).
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
Posted: Fri Sep 18, 2020 11:37 pm
by bradstew
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.
Re: Potential Bug
Posted: Sat Sep 19, 2020 4:20 am
by jimmo
bradstew wrote: ↑Fri Sep 18, 2020 11:37 pm
I tried it on both V1.1 and V1.3.
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!
Re: Potential Bug
Posted: Sat Sep 19, 2020 1:46 pm
by pythoncoder
I can't replicate this on a Pyboard 1.1 or on a Pyboard D SF2W.
Re: Potential Bug
Posted: Mon Sep 21, 2020 4:57 pm
by bradstew
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
Re: Potential Bug
Posted: Mon Sep 21, 2020 5:43 pm
by dhylands
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).
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.
>>>
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)
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.
>>>
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)
Re: Potential Bug
Posted: Thu Sep 24, 2020 8:29 pm
by bradstew
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.
Re: Potential Bug
Posted: Sun Sep 27, 2020 6:58 am
by pythoncoder
this is a clone PYB from China
In which case I'd check the electrical connection of that particular pin. I suspect a hardware problem.
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.
Re: Potential Bug
Posted: Mon Sep 28, 2020 6:20 pm
by bradstew
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.