dead pyboard
-
- Posts: 288
- Joined: Sun May 04, 2014 8:54 am
dead pyboard
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?
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?
Re: dead pyboard
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: 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.
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"
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.
-
- Posts: 288
- Joined: Sun May 04, 2014 8:54 am
Re: dead pyboard
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
No effect.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.
Re: dead pyboard
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.
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.
Re: dead pyboard
after updating to latest master right now and flashing a new firmware into PyBoard - I have same synptoms I still can flash it again, but can't use it
Re: dead pyboard
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)
Re: dead pyboard
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: 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 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): 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.
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
Code: Select all
make BOARD=PYBV11 deploy
Code: Select all
$(info Executing GNUmakefile)
BOARD = PYBV11
$(info BOARD = $(BOARD))
include Makefile
The two info lines remind me that I'm using the GNUmakefile and which BOARD I'm actually building for.
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Re: dead pyboard
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
Index to my micropython libraries.
Index to my micropython libraries.
Re: dead pyboard
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.
Re: dead pyboard
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.
Is there anybody who can compile and run firmare with 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)