New build seems to have killed my Pyboard (now fixed)
Re: New build seems to have killed my Pyboard (now fixed)
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.
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.
- 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)
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.
Index to my micropython libraries.
Re: New build seems to have killed my Pyboard (now fixed)
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)?
- 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)
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
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.
Index to my micropython libraries.
Re: New build seems to have killed my Pyboard (now fixed)
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.
Re: New build seems to have killed my Pyboard (now fixed)
@pythoncoder if it is really a worn out flash I am seriously interested in getting my hands on this particular board.
- 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)
@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.
Index to my micropython libraries.
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
The Pyboard lives!
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.
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.
Index to my micropython libraries.
Re: New build seems to have killed my Pyboard (now fixed)
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:
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).
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"
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).
- 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)
OK, I appreciate I didn't give much information. Firstly a few observations re this laptop.
dmesg output
lsusb output
The device:If I try to connect with Miniterm I get a promising looking screen, but no response to keypresses
screen produces something similar. Rshell won't touch it:
rshell (with my wait mod) here isI'd be very grateful for any suggestions
- 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"
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
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]: ~
Code: Select all
$ ls -l /dev/pyboard
lrwxrwxrwx 1 root root 7 Feb 3 16:02 /dev/pyboard -> ttyACM0
[adminpete@axolotl]: ~
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.
>>>
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]: ~
$
Code: Select all
alias rshell='/usr/local/bin/rshell -p /dev/pyboard --wait 25'
Peter Hinch
Index to my micropython libraries.
Index to my micropython libraries.