I bricked my brand new VLDiscovery board

[andyturk]

Posted on August 11, 2012 at 09:46

About 45 minutes into playing with my new VLDiscovery board, I seem to have bricked it. I downloaded a ''bad'' program onto the thing and now it's telling me that the device is protected and resists all my attempts to put a ''good'' program into flash.

I'm doing all this on OS X (Lion) with opened 0.6.0-rc1. Openocd seemed to work well enough to put the bad code down, so I've got to believe there's some magic incantation that will let me use the same setup to get it working again. The board cost less than $10, but it'd be a shame to throw it away because of some bad bits. I'm pretty sure my opened setup is workable because I can successfully flash a STMF4Discovery board with good code. What I'm missing is some way to bring the VLDiscovery board back.Unfortunately, I don't have access to a windows environment and CrossWorks chokes when I try to install the STM32 packages and thus never sees my board via USB.The board seems generally hosed now with bogus values coming back for the size of flash memory. Is it just a paperweight now?--------------------------------------$ telnet localhost 4444Trying 127.0.0.1...Connected to localhost.Escape character is '^]'.Open On-Chip Debugger> halttarget was in unknown state when halt was requestedtarget state: haltedtarget halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc> mdw 0 4 0x00000000: 40000080 00000000 00000000 00000000 > flash erase_sector 0 0 lastdevice id = 0x10016420flash size = 5384kbyteserased sectors 0 through 5383 on flash bank 0 in 0.029046s> cd /Users/andy/code/chibios/demos/ARMCM3-STM32F100-DISCOVERY> flash write_image build/ch.elfPadding image section 0 with 4 bytesflash write algorithm aborted by targettarget state: haltedtarget halted due to breakpoint, current mode: Thread xPSR: 0x41000000 pc: 0x2000003a msp: 0xfffffffcflash write failed at address 0x8000002flash memory write protectederror writing to flash at address 0x08000000 at offset 0x00000000in procedure 'flash'

[Tesla DeLorean]

Posted on August 11, 2012 at 13:35

If you upload code that impedes the debugger getting control you might want to set BOOT0 to 3V so that when you reset the board it runs the system loader instead of your broken code.

Stuff that breaks the debugger are things like reprogramming the SWD GPIO's, DMA and WFI code.

[andyturk]

Posted on August 11, 2012 at 22:59

After pounding on this some more, I seem to be able to talk to the board. One weird thing is that openocd thinks it has 5384K of flash now, which is obviously wrong. I remember seeing it report the correct number (128K) earlier.

Still can't flash anything to it. Openocd complains that the device is protected and can't seem to unlock it. The texane stlink program reports an error too.Oh well, I'm done with it. If anyone wants a free vldiscovery board (here in the US), get in touch and I'll be happy to put it in the mail.

[Tesla DeLorean]

Posted on August 12, 2012 at 20:57

I don't have a lot of confidence in the OPENOCD stuff, and most of the commercial dev tool market focuses on the PC/Windows market, not least because the HW buy in point is around $200.

Drop me an email a sourcer32@gmail.com we'll figure out how to get you some postage or USB cables, or something.

[andyturk]

Posted on August 13, 2012 at 07:29

Yeah, the commercial tools are coming down in price, but I'd rather slit my wrists than develop on Windoze. When necessary, I can hold my nose and run one of the big name IDEs in Virtualbox, but only as a last result. That didn't work in this case because plumbing an stlink-v1 connection through Virtualbox wasn't working at all.

Fortunately, I also have an F4Discovery board that's working just fine natively with OS X, GCC and openocd. That little F4 beast is fast! It's blowing the doors off the DK-LM3S9D96 I've been using.

[frankmeyer9]

Posted on August 13, 2012 at 11:19

Yeah, the commercial tools are coming down in price, but I'd rather slit my wrists than develop on Windoze.

Crossworks runs under Linux and Mac, too. I'm using it, and I'm not dissatisfied. At least under Linux, the VL_Discovery board is of limited use, because Crossworks does not support the broken STLink V1 implementation under this OS.

[andyturk]

Posted on August 13, 2012 at 16:10

I tried Crossworks (on OS X) to see if it could talk to the board. During installation, it complained it didn't have access (since it was writing files to /Applications) and then it seemed to get lost. It thought files were installed, but they really weren't. Yuck. I didn't want to jump down another rat hole, and set it aside.

I also tried Keil under Virtualbox. After going gray waiting for the 500MB download, it failed to see any of the various ARM devices I tried to show it, probably due to USB issues. But that's OK, I don't really like IDEs anyway.Emacs is my IDE. :)

[frankmeyer9]

Posted on August 13, 2012 at 17:08

I don't have a Mac, so I have no experience with it.I guess Macs seem not primarily intended for SW development purposes...

I do not slit my wrists, but avoid Windows whenever possible. That was one reason for Crossworks. Main issue after installation were access rights to the USB port, which are somehow necessary for debug adapters. Since Mac OS is based on some *nix variant, this might have been the reason for your troubles.But that's OK, I don't really like IDEs anyway. Emacs is my IDE. :) I like the feature of getting predefined debug adapter settings and integrated debug support for a wider range of ARM controllers - not only ST. As a professed Eclipse-hater, I found Crossworks to be the best compromise for me. By the way, I really liked MicroEmacs in Amiga times. Even this downstripped version had features some 'modern' editors/IDEs are missing.

[Tesla DeLorean]

Posted on August 13, 2012 at 18:45

I think a bunch of us here are just fossils, I still prefer my text editor to use WordStar(tm) keys, and unlike an IDE it doesn't eat half my screen real estate with junk.

[andyturk]

Posted on August 13, 2012 at 19:32

''I guess Macs seem not primarily intended for SW development purposes...''

Ouch. LOL