Page 2 of 3
Re: New build seems to have killed my Pyboard (now fixed)
Posted: Thu Jan 14, 2016 7:21 pm
by dhylands
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.
Re: New build seems to have killed my Pyboard (now fixed)
Posted: Tue Feb 02, 2016 10:14 am
by pythoncoder
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
Re: New build seems to have killed my Pyboard (now fixed)
Posted: Tue Feb 02, 2016 12:46 pm
by Damien
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)?
Re: New build seems to have killed my Pyboard (now fixed)
Posted: Tue Feb 02, 2016 4:49 pm
by pythoncoder
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
Re: New build seems to have killed my Pyboard (now fixed)
Posted: Tue Feb 02, 2016 4:58 pm
by Damien
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)
Posted: Tue Feb 02, 2016 10:31 pm
by chuckbook
@pythoncoder if it is really a worn out flash I am seriously interested in getting my hands on this particular board.
Re: New build seems to have killed my Pyboard (now fixed)
Posted: Wed Feb 03, 2016 6:35 am
by pythoncoder
@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.
The Pyboard lives!
Posted: Wed Feb 03, 2016 8:58 am
by pythoncoder
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.
Re: New build seems to have killed my Pyboard (now fixed)
Posted: Wed Feb 03, 2016 3:25 pm
by dhylands
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).
Re: New build seems to have killed my Pyboard (now fixed)
Posted: Wed Feb 03, 2016 4:28 pm
by pythoncoder
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
