New build seems to have killed my Pyboard (now fixed)

[pythoncoder]

[message edited after fault was fixed]
My attempt to install this has left my Pyboard with the LED's apparently showing DFU mode on power up. But it doesn't respond to an attempt to upload a build, nor does it respond to the user switch on boot. The board seems totally FUBAR. Is there any way to retrieve it? Here is a dump of the session.

Code: Select all

$ sudo dfu-util -d 0483:df11 -a 0 -D pybv10-2016-01-13-v1.5.2-54-gefc971e.dfu 
[sudo] password for adminpete: 
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 = 281956)
parsing element 1, address = 0x08000000, size = 14504
parsing element 2, address = 0x08020000, size = 267436
Error during second get_status
[adminpete@axolotl]: ~/Downloads
$ sudo dfu-util -d 0483:df11 -a 0 -D pybv10-2016-01-13-v1.5.2-54-gefc971e.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
No DFU capable USB device found
[adminpete@axolotl]: ~/Downloads
$ 

It probably goes without saying, but I've loaded numerous builds from this PC without issue so I don't think the problem is there. It's a V1.0 Pyboard. It is a bare board with nothing attached beyond the USB cable and the board has been hitherto reliable.

[blmorris]

@pythoncoder - Have you tried the hardware method to force booting into DFU mode yet? You power up the board (or use the reset button) with pin P1 / DFU connected to 3.3V; they are right next to each other on the lower-left corner of the pyboard, one row up from the bottom.
You may have tried it already, but you didn't mention it in your post. I have found it fairly difficult to brick the board via firmware (and with my amateur C coding, I have certainly tried ), but I wouldn't want to rule out the possibility.

-Bryan

[blmorris]

One more thing - I have wondered what it would look like to have a chip fail by exceeding the flash write endurance capacity. The flash is nominally rated to 10,000 erase / write cycles - tough to get there in normal usage, but if an application is frequently writing to the flash sectors implementing the internal filesystem then I could see it happening.
I hope you manage to recover you board!

-Bryan

[stijn]

> if an application is frequently writing to the flash

This was my first thought as well due to past experiences with flash performing less well than advertised. Hard to tell for sure though, unless you have a programmer which can read the flash content back for verification?

[fe2o3]

I believe that's the version I flashed my v1.0 board with last night. No problems and did it from my Raspberry Pi for the first time.

Someone correct me if I'm wrong but I thought when flash goes beyond its "expiration" writes/erases that it simply doesn't write/erase -- reading only the last thing written. Shouldn't stop a board from booting up until the user program, if any, starts up.

-Rusty-

[pythoncoder]

@blmorris I hadn't tried the hardware method, thanks for reminding me

I used it to load an earlier build and proved it worked. Then I loaded the new build, and this time it loaded without error.

I'm mystified as to why it failed the first time. Just one of those things I guess. I don't think flash wear was a cause: though the board gets a good deal of use I've written no programs which perform repeated writes to flash.

[blmorris]

@pythoncoder - Glad you got your board back!

I'm mystified as to why it failed the first time. Just one of those things I guess.

Yeah… there are always those random glitches that could turn out to be just about anything and then stubbornly refuse to repeat. ESD? Cosmic ray? (Supposedly it still happens...) Or is it something that actually needs to be fixed?

For my own sanity, if it doesn't happen twice, I just pretend that it didn't happen once and move on

-Bryan

[dhylands]

My favorite way to semi-brick a board is to accidentally burn the wrong firmware (typically I'll forget to use BOARD= when I do the deploy.

So far, I've been able to recover using the BOOT/DFU button, or if I'm using the 429 and flashing via SWD/JTAG then holding the reset button and releasing it just after starting the flashing procedure.

[pythoncoder]

I'm deeply impressed by the Pyboard's resilience. I've crashed and locked them up more times than I could shake a stick at. Yet as far as I can remember I've only had to resort to the safe boot procedure once or twice in 18 months heavy use. A vanilla uSD card and a power cycle "just works". Until yesterday.

To my shame I once ran one with about 5.5V applied to the 3V3 pin. The failure to actually work and the current draw prompted me to switch off fast but to my surprise it survived the experience intact

[Damien]

A fresh MCU from the factory has the observed behaviour: on power up the LEDs look like they do when in DFU mode but there is no DFU USB device. I think all it's doing is executing 0xffff continuously. That would explain the LEDs: the gpio are not initd so they are floating and weakly power the LEDs.

I have had a few cases where programmed boards fail like the above case but they are rare. Probably an error with the erase/programming.