dead pyboard

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.
Turbinenreiter
Posts: 279
Joined: Sun May 04, 2014 8:54 am

dead pyboard

Post by Turbinenreiter » Fri Nov 28, 2014 1:15 pm

So, one of my boards seems to be dead.

Blue, Yellow and Red LEDs are on, booting while holding user switch does nothing, pulling DFU high does nothing (No DFU capcable USB device found).

Anything I can do?

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

Re: dead pyboard

Post by dhylands » Fri Nov 28, 2014 3:46 pm

The Blue/Yellow/Red LEDs coming on and being dimly lit typically means that the board is in DFU mode.

lsusb should show a device with the ID 0483:df11 when the pyboard is in DFU mode, and f055:9800 (although the 9800 portion may change) when the pyboard is operating normally.

Try running dfu-util -l and if it reports something like this:

Code: Select all

Found DFU: [0483:df11] ver=2200, devnum=6, cfg=1, intf=0, alt=3, name="@Device Feature/0xFFFF0000/01*004 e", serial="385435603432"
Found DFU: [0483:df11] ver=2200, devnum=6, cfg=1, intf=0, alt=2, name="@OTP Memory /0x1FFF7800/01*512 e,01*016 e", serial="385435603432"
Found DFU: [0483:df11] ver=2200, devnum=6, cfg=1, intf=0, alt=1, name="@Option Bytes  /0x1FFFC000/01*016 e", serial="385435603432"
Found DFU: [0483:df11] ver=2200, devnum=6, cfg=1, intf=0, alt=0, name="@Internal Flash  /0x08000000/04*016Kg,01*064Kg,07*128Kg", serial="385435603432"
then the confirms it.

You can also force the board into DFU mode by shorting the DFU pin (pin P1) with 3V3 right next to it, and then pressing reset.

Once in DFU mode, try flashing some new firmware.

Turbinenreiter
Posts: 279
Joined: Sun May 04, 2014 8:54 am

Re: dead pyboard

Post by Turbinenreiter » Fri Nov 28, 2014 5:13 pm

Code: Select all

plam@newlinx:~$ lsusb
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 002: ID 046d:c05b Logitech, Inc. M-U0004 810-001317 [B110 Optical USB Mouse]
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 5986:0300 Acer, Inc 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

plam@newlinx:~$ dfu-util -l
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
So LEDs indicate DFU mode, but device doesn't show up, neither in usb nor as DFU capable.
You can also force the board into DFU mode by shorting the DFU pin (pin P1) with 3V3 right next to it, and then pressing reset.
No effect.

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

Re: dead pyboard

Post by dhylands » Fri Nov 28, 2014 9:49 pm

Well, I think that the LEDs being dimly lit is just a side-effect. My guess is that the pins for the LEDs are configured as inputs with pullups and that's what is causing them to be dimly lit.

It's probably worth while to try a different USB cable, just to make sure that isn't the problem (I've had several USB cables fail on me recently). Its also worth trying a different USB port on your host machine.

I wrote up a blog post on how to serial bootload the STM32F4: http://blog.davehylands.com/2014/02/ser ... m32f4.html

USB mode requires the external crystal in order to work. If for some reason the crystal was bad, then that might explain why its not showing up in DFU mode.
You can also serial bootload using a serial port (without the external crystal).

It is starting to sound like you do have a dead board. But if you want to exhaust the possibilities, then try powering the board using VIN with USB disconnected, and try the serial bootloading process to see if you get any response from that.

User avatar
kamikaze
Posts: 143
Joined: Tue Aug 16, 2016 10:10 am
Location: СССР
Contact:

Re: dead pyboard

Post by kamikaze » Wed Aug 09, 2017 1:42 am

after updating to latest master right now and flashing a new firmware into PyBoard - I have same synptoms :roll: I still can flash it again, but can't use it

User avatar
kamikaze
Posts: 143
Joined: Tue Aug 16, 2016 10:10 am
Location: СССР
Contact:

Re: dead pyboard

Post by kamikaze » Wed Aug 09, 2017 1:53 am

re-flashing with pre-built firmware solved the problem. Looks like this compiler produces wrong binary?

Code: Select all

$ LC_ALL=C arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/arm-none-eabi/gcc-bin/6.4.0/arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/arm-none-eabi/6.4.0/lto-wrapper
Target: arm-none-eabi
Configured with: /var/tmp/portage/cross-arm-none-eabi/gcc-6.4.0/work/gcc-6.4.0/configure --host=x86_64-pc-linux-gnu --target=arm-none-eabi --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/arm-none-eabi/gcc-bin/6.4.0 --includedir=/usr/lib/gcc/arm-none-eabi/6.4.0/include --datadir=/usr/share/gcc-data/arm-none-eabi/6.4.0 --mandir=/usr/share/gcc-data/arm-none-eabi/6.4.0/man --infodir=/usr/share/gcc-data/arm-none-eabi/6.4.0/info --with-gxx-include-dir=/usr/lib/gcc/arm-none-eabi/6.4.0/include/g++-v6 --with-python-dir=/share/gcc-data/arm-none-eabi/6.4.0/python --enable-languages=c --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 6.4.0 p1.0' --disable-esp --enable-poison-system-directories --disable-shared --disable-libatomic --disable-threads --without-headers --disable-bootstrap --with-newlib --enable-multilib --disable-altivec --disable-fixed-point --disable-libgcj --disable-libgomp --disable-libmudflap --disable-libssp --disable-libcilkrts --disable-libmpx --disable-vtable-verify --disable-libvtv --disable-libquadmath --enable-lto --without-isl --disable-libsanitizer --enable-default-pie --enable-default-ssp
Thread model: single
gcc version 6.4.0 (Gentoo 6.4.0 p1.0)

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

Re: dead pyboard

Post by dhylands » Wed Aug 09, 2017 3:15 am

Make sure you're specifying the correct board.

The default board is for the PYBV10 which is the 1.0 board. The boards currently being sold are almost certainly 1.1 board, so you need to build using:

Code: Select all

make BOARD=PYBV11
You need to specify the BOARD= parameter on ALL make commands. So to flash a 1.1 board you'd need to also use:

Code: Select all

make BOARD=PYBV11 deploy
Code built for a 1.0 board will not run on a 1.1 board or vice-versa since the 2 boards have different frequency crystals. When I'm building for a particular board alot, then I tend to create a GNUmakefile in the same directory as the Makefile with something like the following in it (not that the case of the filename GNUmakefile is important):

Code: Select all

$(info Executing GNUmakefile)
BOARD = PYBV11
$(info BOARD = $(BOARD))
include Makefile
then I can just use make and it will default to building PYBV11 but you can still override it by passing BOARD= on the make command line.
The two info lines remind me that I'm using the GNUmakefile and which BOARD I'm actually building for.

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

Re: dead pyboard

Post by pythoncoder » Wed Aug 09, 2017 5:26 am

If you're on Linux the script buildpyb detects the connected board, builds and deploys the appropriate build. https://github.com/peterhinch/micropyth ... /fastbuild
Peter Hinch

User avatar
kamikaze
Posts: 143
Joined: Tue Aug 16, 2016 10:10 am
Location: СССР
Contact:

Re: dead pyboard

Post by kamikaze » Wed Aug 09, 2017 3:04 pm

thanks. Will try that, but I have all env variables set as bash alias for a long time and it did work. Then some time passed and I've got GCC 6.4 ) will dig into the problem deeper.

User avatar
kamikaze
Posts: 143
Joined: Tue Aug 16, 2016 10:10 am
Location: СССР
Contact:

Re: dead pyboard

Post by kamikaze » Sun Oct 29, 2017 9:24 pm

same problem with GCC 6.4. Successful compilation and firmware update - but pyboard fails to start. For me it seems there is something wrong while using GCC 6.4.

Code: Select all

$ LC_ALL=C arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/arm-none-eabi/gcc-bin/6.4.0/arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/arm-none-eabi/6.4.0/lto-wrapper
Target: arm-none-eabi
Configured with: /var/tmp/portage/cross-arm-none-eabi/gcc-6.4.0/work/gcc-6.4.0/configure --host=x86_64-pc-linux-gnu --target=arm-none-eabi --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/arm-none-eabi/gcc-bin/6.4.0 --includedir=/usr/lib/gcc/arm-none-eabi/6.4.0/include --datadir=/usr/share/gcc-data/arm-none-eabi/6.4.0 --mandir=/usr/share/gcc-data/arm-none-eabi/6.4.0/man --infodir=/usr/share/gcc-data/arm-none-eabi/6.4.0/info --with-gxx-include-dir=/usr/lib/gcc/arm-none-eabi/6.4.0/include/g++-v6 --with-python-dir=/share/gcc-data/arm-none-eabi/6.4.0/python --enable-languages=c --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 6.4.0 p1.1' --disable-esp --enable-poison-system-directories --disable-shared --disable-libatomic --disable-threads --without-headers --disable-bootstrap --with-newlib --enable-multilib --disable-altivec --disable-fixed-point --disable-libgcj --disable-libgomp --disable-libmudflap --disable-libssp --disable-libcilkrts --disable-libmpx --disable-vtable-verify --disable-libvtv --disable-libquadmath --enable-lto --without-isl --disable-libsanitizer --enable-default-pie --enable-default-ssp --disable-libstdc++-v3
Thread model: single
gcc version 6.4.0 (Gentoo 6.4.0 p1.1)
Is there anybody who can compile and run firmare with GCC 6.4?

Post Reply