Potential Bug

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
bradstew
Posts: 17
Joined: Thu Nov 29, 2018 9:29 pm

Potential Bug

Post by bradstew » Fri Sep 18, 2020 9:32 pm

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.

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

Re: Potential Bug

Post by dhylands » Fri Sep 18, 2020 11:25 pm

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

bradstew
Posts: 17
Joined: Thu Nov 29, 2018 9:29 pm

Re: Potential Bug

Post by bradstew » Fri Sep 18, 2020 11:37 pm

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.

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

Re: Potential Bug

Post by jimmo » Sat Sep 19, 2020 4:20 am

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!

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

Re: Potential Bug

Post by pythoncoder » Sat Sep 19, 2020 1:46 pm

I can't replicate this on a Pyboard 1.1 or on a Pyboard D SF2W.
Peter Hinch

bradstew
Posts: 17
Joined: Thu Nov 29, 2018 9:29 pm

Re: Potential Bug

Post by bradstew » Mon Sep 21, 2020 4:57 pm

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

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

Re: Potential Bug

Post by dhylands » Mon Sep 21, 2020 5:43 pm

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)

bradstew
Posts: 17
Joined: Thu Nov 29, 2018 9:29 pm

Re: Potential Bug

Post by bradstew » Thu Sep 24, 2020 8:29 pm

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.

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

Re: Potential Bug

Post by pythoncoder » Sun Sep 27, 2020 6:58 am

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.
Peter Hinch

bradstew
Posts: 17
Joined: Thu Nov 29, 2018 9:29 pm

Re: Potential Bug

Post by bradstew » Mon Sep 28, 2020 6:20 pm

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.

Post Reply