So the mbed arrives today so I can use as my platform for quickly testing units of code before pushing to my primary board. Just to test this thing loaded up an scmRTOS example from the public repository. Guess what, runs fine but never seen by Linux, OSX, or Windows as a usb drive after loading the scmRTOS program example out there.

This tells me there is a serious flaw and a known defect since the "dead mbed" issues is known and document as per this site.

I would like to see the support guys some up with a solution to this as it is quite obvious there is a flaw in the bootloader/bootstrap code and not the ARM code which is being run on it uploaded by the user. Especially when it is the mechanism (the lets trick the PC in to recognizing this as a usb drive) that is the issue.

Based on your description of the problem it sounds like holding down the reset button (and only releasing it after you have copied up a new binary) might actually let your PC see the device as a USB mass storage device if your sample scmRTOS program was using the FLASH storage for its own purposes.

Hi Gary,

Sorry you are having problems. Let's try any understand what is up...

1) If you work through the deadmbed page methodically, where do you end up? It is a good place to help understand how the mbed works and things that can ocassionally trip up new users. You may find it highlights something you haven't yet tried.

2) What example are you running exactly? Can you provide a link? As the behaviour is probably caused by the program you are running, this would help see what it may be doing. As Adam says, it could well be accessing the USB disk (which therefore hides it from the host) and if so, holding down reset will keep the target program from running, and hence the drive would appear.

Hope we can get you back up and running soon,

Thanks, Simon

Actually as an engineer myself i was testing the board to do spot checks on code I am working on for my own Cortex-M3 board for specific application.

Holding down the reset is the only viable option to try and get this in to a mode which any PC will recognize under any OS. However, having done so numerous times prior to posting I can tell you this is a state which has not been planned for.

The code which was loaded was scmRTOS_test by Igor. This worked just fine. The additional step I took was to use the device as temporary storage to move a zip file (zipped source code) to another PC. So the mbed flash contained the scmRTOS_test.bin file, a source.zip file containing my code I was moving to another PC to import to the compiler online. The source zip file was about 768K. Clearly under the limit of the device.

However, the combination of having the scmRTOS_test.bin, mbed.htm, and source.zip created an issue which does not allow any PC to see the device as a USB Drive. All that happens is scmRTOS_test runs each time. If you look at scmRTOS_test it has no local file system handling so should not be causing the issue. Likewise, when running scmRTOS_test the device was able to be mounted since I was able to copy the source.zip file to it.

This is a situation which was not planned for. There are many circumstance where one would want to move a file to the device along with a bin file such as in logging, configuration, or analysis data.

The mechanism for moving a program to the device is certainly easy and has merit, but the implementation is a bit flawed given the condition of the board with just such a simple set of steps. It would be nice to see an alternate way to restore a board to get firmware on it for just such a situation.

The only resolution I see is for mbed to replace my board with a new one and then take my board and review the condition under which it is operating to make adjustments to their bootstrap and mitigate the issue from biting other users.

UPDATE: Chris is going to ship me a new one and I will send the board back for a postmortem since it could be possible that the FLASH has failed on the device. The scenario I described is something which others do as far as moving files around so seems more likely what Chris described as a possible FLASH memory failure.

strange ?!

Perhaps mbed needs a jumper/push-button upon power up to "reformat" the file system on the flash in case it becomes corrupt such that the mbed is "bricked"

Mine bricked last week. The mbed guys are awesome though. They got a new one to me free of charge. I didn't have the exact same bricking situation but it is still dead (mine shows up as a flash drive but won't run code). I now have (and plan to keep) two mbeds on hand at all times. Things fail. It just happens :)

Would it be possible to repair this problem by soldering some wires onto the flash IC's pins and then using some method to write a flash image?

Was the cause for this problem ever found?

And a solution to use locally, other than sending the Mbed back?

Thanks, Gary

Frank,

Search the forums for 'wiggler' and 'JTAG'. You should find a thread that describes how to add a direct JTAG connection that can be accessed via OpenOCD, etc.

Thanks Fred, this was 2 years ago, I now own several JTAG and SWD debuggers