pyboard v1.1 stuck and not recognized

[jonpedros]

(Made this question before in the forum, so reposting here)

Hello everyone.

I've bought a pyBoard v1.1 recently and it worked correctly with my code. However, after upgrading the firmware from v1.16 (not sure) to 1.19.1 through DfuSe without errors, the board got really weird, failing to connect to my program. After a bit of random resetting and filesystem resetting to no avail, I decided to try to upgrade again, wondering if I used a wrong firmware version. The upgrade was interrupted midway with an error.

Now the pyBoard is stuck with the blue and red LEDs flashing rapidly, and the yellow one faintly lit. The board is not identified at all by Windows, not even as malfunctioning device. My PC has the specific micropython drivers, but the other PC I tried does not. I tried different micro USB cables and tried connecting to another PC, but it won't show up. It also does not respond at all to the reset and USR buttons.

Finally tried connecting the 3V3 pin to the BOOT0 and to go into DFU mode (the instruction would normally be to also press reset after that, but I noticed this doesn't change the result); this makes the LEDs go off for a second 3 or 4 times, after which they all turn off and the board is finally recognized by Windows, but its instantly identified as a malfunctioning USB device. It does not show up on DfuSe as a DFU device.

Attached is a photo of the board (the LEDs lit on the photo are the flashing ones)

I thought I might try the pins connection with proper jumper cables, but I'm not sure about which would work. Are these okay for that?

https://www.amazon.co.jp/-/en/KKHMF-inches-Breadboard-Jumper-Female/dp/B072KH53HR/

Thank you for your time!

[peterhinch]

Your photo shows the Pyboard mounted on some other PCB. Could that board be affecting firmware loading? I would detach the Pyboard completely, link 3V3 to BOOT0 and try again. Firmware loading on a Pyboard is normally very straighforward.

[robert-hh]

It looks like this carrier board: https://pycontrol.readthedocs.io/en/latest/

[jonpedros]

Sorry to take so long to reply. I thought I was replying but only added a post to the discussion.

For linking the pins, should I get jumper cables or are solutions such as using conductors (i.e. needles, wires, etc) good enough?
If jumper cables are best, I would prefer to use it. But are the ones such as the linked one below good enough? (Or, if you could send me a pic/example/spec of suitable cables that would be very helpful)

[(https://www.amazon.co.jp/-/en/KKHMF-inches-Breadboard-Jumper-Female/dp/B072KH53HR/)]

Thank you very much for the support.

[jimmo]

Paperclip or anything conductive is fine! You just need to bridge those two pins for the moment while the reset button is pushed. Anything will do.

[jonpedros]

So, now I've taken the board off the breakboard but the result is exactly the same. I show it here on this video:

https://youtu.be/eU2EjmO0rEU

I'm wondering what to try next, or if there could be something broken on the micropython board.

[jonpedros]

(sorry for double post)

When I try bridging the pin while holding reset I get no change from the flashing lights.

[dhylands]

In particular, you probably want to review this document: https://www.st.com/resource/en/application_note/cd00167594-stm32-microcontroller-system-memory-boot-mode-stmicroelectronics.pdf Chapter 29 covers the STM32F405. There are quite a few pins checked by the bootloader. The flow chart on page 133 shows the order that it looks for things. Disconnecting everything from the pyboard leaves all of the pins in a good state.

Fashing new firmware doesn't erase the filesystem, so you may want to try doing a "mass erase". This script will perform a mass-erase using dfu-util: https://github.com/dhylands/upy-examples/blob/master/mass-erase.sh Doing the mass erase will completely wipe the flash of firmware and filesystem and then when you reflash the firmware and that firmware runs it will create a new empty file system.

[jonpedros]

Sorry to take so long to reply. I thought I was replying last month but only added a post to the discussion.

So, now I've taken the board off the breakboard but the result is exactly the same. I show it here on this video.

Also, when I try bridging the pin while holding reset I get no change from the flashing lights.

You mentioned running a script though dfu-util, but do you think the board will be identified during it's current state?

[jonpedros]

Anyone has some clue?

[peterhinch]

The video isn't clear but the sequence should be to short the pins together with the board powered down, apply power with the short still in place, then remove the short. All the LEDs should be dimly lit with no flashing. If this isn't the case, the Pyboard hardware is suspect.

[jonpedros]

Thank you for the support.

I see. I'll try that sequence. So, in other words, there's no need to press reset after all?

[jimmo]

Reset is the same as power cycle.

The point is -- when the stm32 boots (either from power up or from reset), if BOOT0 is shorted to VCC, then it enters the bootloader.