New build seems to have killed my Pyboard (now fixed)

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.
User avatar
dhylands
Posts: 3821
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: New build seems to have killed my Pyboard (now fixed)

Post by dhylands » Thu Jan 14, 2016 7:21 pm

I found an app note that says that on reset, the JTDI, JNTRST, JTMS/SWDIO, and JTCK/SWCLK pins all have the internal pullups enabled.

On the pyboard, PA13/14/15 (3 of the 4 LEDs) are connected to JTMS/JTCK/JTDI which explains the dimly lit state. They're being powered by the internal pullup resistors which on the order of 40-50K ohms.

DFU mode doesn't explicitly initialize those pins, which is why they stay that way when DFU is running. MicroPython initializes the pins which turns the pullups off.

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

Re: New build seems to have killed my Pyboard (now fixed)

Post by pythoncoder » Tue Feb 02, 2016 10:14 am

This error occurred a couple of times but has now become a hard fault on this particular Pyboard. Flashing any build fails. The board is V1.0 and has no SD card fitted; there is no hardware attached apart from the link from 3V3 to BOOT0. Is the board toast or is there any way it might be rescued?

Code: Select all

[adminpete@axolotl]: ~/Downloads
$ sudo dfu-util -d 0483:df11 -a 0 -D pybv10-2016-02-02-v1.6-3-g67e8108.dfu 
dfu-util 0.5

(C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc.
(C) 2010-2011 Tormod Volden (DfuSe support)
This program is Free Software and has ABSOLUTELY NO WARRANTY

dfu-util does currently only support DFU version 1.0

Filter on vendor = 0x0483 product = 0xdf11
Opening DFU USB device... ID 0483:df11
Run-time device DFU version 011a
Found DFU: [0483:df11] devnum=0, cfg=1, intf=0, alt=0, name="@Internal Flash  /0x08000000/04*016Kg,01*064Kg,07*128Kg"
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
Dfu suffix version 11a
DfuSe interface name: "Internal Flash  "
file contains 1 DFU images
parsing DFU image 1
image for alternate setting 0, (2 elements, total size = 283588)
parsing element 1, address = 0x08000000, size = 14504
Error during second get_status
[adminpete@axolotl]: ~/Downloads
Peter Hinch
Index to my micropython libraries.

Damien
Site Admin
Posts: 647
Joined: Mon Dec 09, 2013 5:02 pm

Re: New build seems to have killed my Pyboard (now fixed)

Post by Damien » Tue Feb 02, 2016 12:46 pm

It may be that the flash is worn out. How old is the board (what's the Jaltek serial number)? How often did you write to it (firmware and/or internal flash drive)?

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

Re: New build seems to have killed my Pyboard (now fixed)

Post by pythoncoder » Tue Feb 02, 2016 4:49 pm

S/N 0254240101-1355. Out of interest, how old does that make it?

I've no idea how often I've written to it: it's had a busy life as the one I use for general testing. While I never write code that repeatedly writes to flash, it has been flashed numerous times and will have had files copied to the flash drive repeatedly. It's shown one or two signs of trouble lately so I'm not surprised it's croaked.

I appreciate flash is finite; if it's worn out I know how it feels. I'll bury it with full military honours ;)
Peter Hinch
Index to my micropython libraries.

Damien
Site Admin
Posts: 647
Joined: Mon Dec 09, 2013 5:02 pm

Re: New build seems to have killed my Pyboard (now fixed)

Post by Damien » Tue Feb 02, 2016 4:58 pm

Ok, that's from the second manufacturing run (after the Kickstarter run), done in September 2014. If you've used it heavily then it could indeed be the flash wearing out.

chuckbook
Posts: 135
Joined: Fri Oct 30, 2015 11:55 pm

Re: New build seems to have killed my Pyboard (now fixed)

Post by chuckbook » Tue Feb 02, 2016 10:31 pm

@pythoncoder if it is really a worn out flash I am seriously interested in getting my hands on this particular board.

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

Re: New build seems to have killed my Pyboard (now fixed)

Post by pythoncoder » Wed Feb 03, 2016 6:35 am

@chuckbook You're welcome to it but do tell what you plan to do with it :? I'll send you a PM with my email address.
Peter Hinch
Index to my micropython libraries.

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

The Pyboard lives!

Post by pythoncoder » Wed Feb 03, 2016 8:58 am

Problems with my other spare Pyboard made me smell a rat. The USB subsystem on this Mint laptop is broken: I can't communicate with a working Pyboard using rshell or miniterm. My Debian boxes can flash the "broken" Pyboard without issue so it lives to fight another day...

An odd fault but if I can't fix it perhaps it's time for a new distro. Any ideas from Linux gurus gratefully received - it's a software issue as all USB ports on this laptop are affected.

@chuckbook Sorry I can't (yet ;)) provide a worn-out Pyboard but I'd still love to know what use you have for one.
Peter Hinch
Index to my micropython libraries.

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

Re: New build seems to have killed my Pyboard (now fixed)

Post by dhylands » Wed Feb 03, 2016 3:25 pm

Does anything show up in lsusb? What about dmesg?

A new pyboard will have USB Mass Storage enabled, which means that it will show up with a different PID that one with USB Mass Storage disabled.

I tend to drop the ATTRS{idProduct} to cover all of the various cases, so my /etc/udev/rules.d/49-pyboard.rules file looks like this:

Code: Select all

# f055:9800, 9801, 9802 MicroPython pyboard
ATTRS{idVendor}=="f055", ENV{ID_MM_DEVICE_IGNORE}="1"
ATTRS{idVendor}=="f055", ENV{MTP_NO_PROBE}="1"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="f055", MODE:="0666"
KERNEL=="ttyACM*", ATTRS{idVendor}=="f055", MODE:="0666"
I have a separate file to cover the pyboard in DFU mode.

Some USB ports will shutdown the host side if the device draws too much current.

For Ubuntu, (which Linux Mint is based on), there were a few kernel versions where the serial driver was broken (kernel version 3.13.0-63 works, 3.13.0-65 was broken, and I don't know exactly when it was fixed, but shortly after that).

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

Re: New build seems to have killed my Pyboard (now fixed)

Post by pythoncoder » Wed Feb 03, 2016 4:28 pm

OK, I appreciate I didn't give much information. Firstly a few observations re this laptop.
  • I can communicate with the Pyboard via a UART.
  • Reverting to an earlier kernel via the Grub menu did not fix the problem.
  • The USB ports work with the FDTI adaptor and with USB sticks.
  • boot.py has pyb.usb_mode('CDC').
  • It worked reliably for a year before degrading to the point where it's now a hard fault.
  • No significant changes to the OS apart from periodic apt-get update && apt-get upgrade.
  • I've modified my udev rules (it was very similar) to no effect. (I use the symlink to avoid the TTYACM0/1 problem).

Code: Select all

# f055:9800, 9801, 9802 MicroPython pyboard 
ATTRS{idVendor}=="f055", ENV{MTP_NO_PROBE}="1"
ATTRS{idVendor}=="f055", ENV{ID_MM_DEVICE_IGNORE}="1" 
SUBSYSTEMS=="usb", ATTRS{idVendor}=="f055", MODE:="0666"
KERNEL=="ttyACM*", ATTRS{idVendor}=="f055", SYMLINK+="pyboard", MODE:="0666"
dmesg output

Code: Select all

[   33.686886] usb 3-9: New USB device found, idVendor=f055, idProduct=9802
[   33.686893] usb 3-9: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   33.686897] usb 3-9: Product: Pyboard Virtual Comm Port in FS Mode
[   33.686900] usb 3-9: Manufacturer: MicroPython
[   33.686903] usb 3-9: SerialNumber: 347B354A3333
[   33.709280] cdc_acm 3-9:1.0: This device cannot do calls on its own. It is not a modem.
[   33.709899] cdc_acm 3-9:1.0: ttyACM0: USB ACM device
[   33.710107] usbcore: registered new interface driver cdc_acm
[   33.710111] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
lsusb output

Code: Select all

$ lsusb
Bus 002 Device 002: ID 8087:8000 Intel Corp. 
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:8008 Intel Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 006: ID f055:9802  
Bus 003 Device 003: ID 04f2:b477 Chicony Electronics Co., Ltd 
Bus 003 Device 002: ID 138a:003f Validity Sensors, Inc. 
Bus 003 Device 004: ID 8087:07dc Intel Corp. 
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
[adminpete@axolotl]: ~
The device:

Code: Select all

$ ls -l /dev/pyboard 
lrwxrwxrwx 1 root root 7 Feb  3 16:02 /dev/pyboard -> ttyACM0
[adminpete@axolotl]: ~
If I try to connect with Miniterm I get a promising looking screen, but no response to keypresses

Code: Select all

$ mt
--- Miniterm on /dev/pyboard: 9600,8,N,1 ---
--- Quit: Ctrl+]  |  Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
MSC disabled in boot.py: can't mount drives
MicroPython v1.6-8-g5f3e005 on 2016-02-03; PYBv1.0 with STM32F405RG
Type "help()" for more information.
>>> 
screen produces something similar. Rshell won't touch it:

Code: Select all

[adminpete@axolotl]: ~
$ rshell
Connecting to /dev/pyboard ...
Waiting 25 seconds for pyboard ..........................
failed to access /dev/pyboard
[adminpete@axolotl]: ~
$ ls -l /dev/pyboard
lrwxrwxrwx 1 root root 7 Feb  3 16:02 /dev/pyboard -> ttyACM0
[adminpete@axolotl]: ~
$ 
rshell (with my wait mod) here is

Code: Select all

 alias rshell='/usr/local/bin/rshell -p /dev/pyboard --wait 25'
I'd be very grateful for any suggestions :)
Peter Hinch
Index to my micropython libraries.

Post Reply