I just got an mbed.  I've downloaded my first piece of code to it (the default "flash LED1" program) and it works great.

I tried to change the program to do a sweep of the LED's 1-4 on, 1-4 off and repeat...

#include "mbed.h"              

DigitalOut led1(LED1);
DigitalOut led2(LED2);
DigitalOut led3(LED3);
DigitalOut led4(LED4);

int main() {
    while(1){
    led1 = 1;
    wait(1);
    led2 = 1;
    wait(1);
    led3 = 1;
    wait(1);
    led4 = 1;
    wait(1);
    led1 = 0;
    wait(1);
    led2 = 0;
    wait(1);
    led3 = 0;
    wait(1);
    led4 = 0;
    wait(1);
    }
}

I compiled and downloaded the program, hit the reset button, but the original program (the one that just flashes LED1) continues to run - it doesn't run the newest binary file that's downloaded to the device.

I've tried formatting the mbed drive (hold reset while plugging in, formatting, and unplugging) as described in one of the forum posts.

I'm at wit's end.  Is the device damaged, or is the firmware hosed, or what?

Any help would be appreciated.

Hi Chris,

If you delete all the files off the mbed, and hit reset, can you confirm it does nothing (i.e. it will hold the target in reset, so you shouldn't see any lights flashing).

And if you then download the hello world binary from http://mbed.org/nxp/lpc1768/, that then runs ok?

Simon

Have you tried deleting the original program before dropping your program on to it?

What happens if you try running the device with no program installed?

Thanks for the replies. 

No matter what I do, it continues to run the "flash LED1" default program that I originally compiled and ran.  If all files are deleted, and you hit reset, it still runs the "flash LED1" program.  Not what I was expecting when I bought the thing.  I was expecting to do a bit more with this thing.

I've tried all of the following...

1. Delete files, press reset button
2. Unplug device, plug it back in  - in addition, same process plus press reset button after it's plugged back in
3. hold reset with device unplugged, keep reset pressed while plugging back in and release reset
4. hold reset with device unplugged, plug in and format (both quick and complete format), and unplug still keeping reset pressed, then plug back in (as well as release reset while it's still plugged in

At one point, the device was okay after I completed (4).  But it's back to its old tricks after sitting on the desk over the weekend - continues to run "flash LED1". 

Interestingly, when I'm holding reset and plug in the mbed, the "flash LED1" program runs even while reset button is held - definitely not normal or expected behavior. 

In addition, the unit seems to be getting kind of warm to the touch after it's been plugged in for a while - which makes me think that the hardware itself might be defective.  

I'd really like to know if there's something I might be able to do (like reload the firmware or something) to completely wipe the device and see if I can't start from scratch.  I have access to an AVRISP mkII, and an ICD2, but have no idea if I can (or need to) use either to reload the firmware onto this device so I can at least see if it's salvageable.  If there's a standard method for reloading firmware via usb, that would be preferable, but if there's a step-by-step for reloading firmware via JTAG, that's probably do-able if one of the programmers I have is compatible. 

Thanks for any advice or suggestions.

Chris

Hi Chris,

It is certainly possible to update firmware via USB. You can simply drag on a firmware file and it'll get eaten up, see:

• http://mbed.org/handbook/Firmware

However, I'm not convinced that will solve your problem. It sounds more like it could be an intermittent hardware thing (as a guess, a dry joint might cause the behaviour, and flexing of the board makes it occasionally work which maybe how it passed production test ok).

Drop us a line at support@mbed.org with your mailing details, and we'll organise getting a new one out to you. We'll get you up and running!

Thanks,

Simon

Chris MacGregor wrote:

Interestingly, when I'm holding reset and plug in the mbed, the "flash LED1" program runs even while reset button is held - definitely not normal or expected behavior.

 

No, the reset button seems to work.  When I hold the reset down, the TXRX LED goes out - same if I connect GND to nR. 

Connecting GND to nR allowed me to try some other things as well.  So when it's in reset (nR-GND), LED1 is blinking, but after a while, it stops...sometimes.  This wreaks to me of either a bad PCB (intermittent or high impedance trace) or the aforementioned notorious "dry solder joint". 

I left it in reset for a long time - like 5min - and the led finally stopped flashing.  (I had tried grounding each of the digital io pins, and occasionally, the unit would look as though it was trying to reset - the LED1 would stop flashing momentarily).  So when I found that all the LED's were off and stayed off, I tried downloading new code (listed above) put it in reset again, and it worked.  I then modified the code, and it worked again, with no issues. 

Now it seems to be working fine.  I've updated the code several times(each change worked as expected), deleted all files (worked as expected - did nothing), loaded files back again (worked as expected), and it seems to be working just fine. 

I don't trust it though.  Having to hold the unit in reset for a long long time is not ideal.  I don't want to worry about intermittent hardware bugs while trying to debug software that will need to be debugged heavily and aggressively :).  I also notice that the 1768 is cooler now - which probably means the PCB is cooler, and parts nearby are cooler.  Again, wreaks of bad PCB or cold solder joint.  I'm thinking about getting the heat gun and seeing if cooking it puts it back in the previous state.

Chris

Okay - got a new mbed and it's running great.  Must have been a hardware problem on the other board.  Thanks to all for the help. 

Chris

Chris

Got my mbed recently and mine is also fussy with the reset button.  I can't always be certain I"m running the new code version after a download.  Most often, it requires holding the reset button down for many seconds and then many repeated button operations to get the new code to execute.  Guess I could alternative LEDs on each code update but I may need them for other debug tests.  And I'm afraid I'll be wearing this button out soon.   It seems like it takes a "magic" touch on this button to get reliable code updates.

I'm wondering about the effectiveness of the 'debounce' function for this button on the board - since I only found a RC filter on one of the schematics.  I've found RC filters to be touchy for debouncing mechanical switches - I've had to carefully tolerance the RC components and characterize the switch to get reliable operation.  Is the problem completely gone with your new mbed board?

Dave

Dave,

The new mbed is running strong, so I'm guessing the original device was just bad (whether it was the switch or the PCB, I can't be sure).  I really didn't debug any more than what I described above. 

As an aside, I'd be interested to know if anyone had had a chance to look at the part I sent back.  Two posts in a forum certainly don't indicate a quality problem, but if issues like this can be avoided by a mechanically and electrically compatible component change, it might be worth a look.

Chris

Chris

I hooked up the serial emulation (via USB) and by using 'printf' statements I can do more testing of the reset button.  Seems to be working fine.   Most times, I get my 'printf' statement on reset.  So, I don't think the reset button is the issue.  However, on rare occasions, I don't get my printf statement and the part/board appears to be hung - especially after re-flashing.   And more frequently, after re-flashing, the old code is running.  I dumped the Flash configuration register contents to the terminal and noticed that my setting was for the default of 4 clocks or up to 80Mhz processors - according to the data sheet.  My understanding is the mbed LPC1768 board is clocked at 96Mhz (quoting the web page "Cortex-M3 Core running at 96MHz").  And my board is stuffed with a 100Mhz part.  So, I'm wondering about the default Flash configuration setting.   I interpret this to mean the setting is for up to a 80Mhz part and I have hardware that could be running as fast as 96Mhz.

Looking at the data sheet for the LPC17xx it appears the flash memory is 50ns access.  Assuming 96Mhz and using 4 clocks, this gives my part 41.6ns access time - which would be too short.   Instead of wading thru all the many clock configuration registers - I'd like to try slowing down the processor to test this theory - and I'm looking for code to write to the Flash configuration register or code to write to the many clock registers (yes, I could spend more time hacking , but I'd rather leverage some existing code).

Has anyone seen any code to write to FLASHCFG on the processor or code to change the internal clock speed with the PLLs and clock dividers? And I realize this could change my serial UART settings.

Dave

Just a short note on my recent experience...

My new mbed gave me fits similar to the users above. I had problems resetting, my computer would not recognize the board when I plugged it in, I could not write files to it because my file system did not find the drive. Other times everything worked fine. I tried but was unable to reformat the drive. After messing around looking for an answer here and elsewhere I decided to swap out the USB cable that came with the mbed.

Success! As unlikely as it sounds, the cable was causing intermittent problems, including driving me nuts. I used the heck out of it into the night last night, and again this AM and everything works as advertised.

I seem to have forgotten one of my troubleshooting axioms..."Try the simple things first, even if you think they are unlikely to be the problem."

Best to all,

Russ

Russ/Chris

What operating system are you using?
i.e. Win,Mac.Linux?

Dave

WinXP Media Center, SP3.

WinXP SP3. 

I do have to say though, I never had any issues with Windows seeing or communicating with my device.  Just issues on the mbed side running code I downloaded and resetting properly (reset issues and/or Flash/EEPROM issues).

My mbed is running fine now, I think I can say that 100% of my problems were related to a bad cable.

Best,

Russ

Russ/Chris

Thanks your info is helpful.  I'm running Linux and that seems to be the hitch.

Dave

In addition to trying a new cable, try bypassing USB hubs or using a different port. I have seen a bad hub that caused the USB line voltage to drop to 4V under load. You can also try powering the Vin terminal with 4 AA batteries.

Mike

Good suggestion.  However, in my situation, I had measured voltages on my board and I was running around 4.9V from USB and there was a solid 3.3V on the IC's.   But yes, if USB Vbus sags too low that could explain some flakly hardware.

FWIW, my particular problem appeared to be an error in my  'fstab' in Linux ('/etc/fstab' automatically mounts the mbed 'drive' on most Linux distros).  If you don't get this working, then symptoms will appear that make the mbed looked 'bricked'.   The mbed will appear to be mounted OK and you can write new code files, but It will not run the latest code, and my board would eventually hang up (aka 'bricked').   I could recover by cycling power and making many reset button assertions.   But with the act of plugging/unplugging the USB cable to cycle power, this automatically re-mounts the drive and typically the mbed would resume executing code again  - but it didn't 'sync' the latest code.  BTW, there is a 'how to' post on 'sync' for MAC and Linux users on this website.  Bottom lins is that all of this mayhem can make your mbed look like flaky hardware.  Anyway, I'm now hoping I have moved past this 'issue'.

Dave

A multimeter will not always tell you about power problems, especially if your load is highly variable. Use an oscilloscope to be really sure.

I have a button in GKrellm set to sync the disks, which I always click before pressing the reset button.

Mike Lu wrote:
In addition to trying a new cable, try bypassing USB hubs or using a different port. I have seen a bad hub that caused the USB line voltage to drop to 4V under load. You can also try powering the Vin terminal with 4 AA batteries.

Good point...I did try all of my USB ports during troubleshooting. They all exhibited the same symptoms. New cable, flawless on all ports. Surprising, but true!

Best,

Russ

Just want to say, I have numerous dev tools and toolchains on my machine. I also run XP , every time I try sp3 i yield similar results on other MFG product.  Im willing to bet most of the issues that are not "crisp" usb jacks or bad cables , or hubs with out the power to drive the programming sequence , will land up being xp sp3 .  Any time I get a new dev tool I plug and unplug the usb cable a few times. When I first started playing with usb, 2 tools in a row showed the crisp jack issue.

As for running sp3 , the fix for that one was dont let it install sp3.  I had nothing but problems with it from IDE's closing but staying open in the system, to usb devices not working , and actually blew out a usb hub .

Hi Jim:

I also have used other development tools, though probably not as many as you, but have not had any problems that traced back to SP3. I'll certainly keep it in mind in the future.

I'm assuming a "crisp jack" is a new, not "broken in" connector?

In my view, cables and connectors should work right out of the box assuming they have been kept clean. In the "old days" cables were repairable, even home made. Now, in the age of molded-in connectors, repair is just not worth if. If one gives me trouble it goes in the "bad-cable" stash, and eventually to the recycle center with my 3.5" floppy drives and spare IDE cables.

Best,

Russ

Hi all, I think I have bricked my mbed. Whenever I press the reset button, it does nothing... The middle LED still stays on(which normally turns off to load a new program). When plugged in USB, the computer is able to detect it and the middle LED blinks a few times, but then it stays on and doesnt let me load up a new program.

I have tried all of the above methods: updating firmware, holding reset button while unplugged/formating etc etc. but non seem to fix the program. I have also tried using the GND and NR and sending a break through a terminal.

please help, thanks

Hu Tung,

I made a page for tracking down this sort of thing:

• http://mbed.org/cookbook/deadmbed

It sounds like it doesn't cover your case, so it'd be great to track it down!

I think you are saying it isn't loading the program, but is appearing as a disk fine and the interface is active (status LED flashes when you plug it in). Some other things I can think of:

• Is the disk full?
• Can you successfully copy a program on to the disk (so when you unplug and replug, it is still there?
• What OS are you on, and have you tried a different PC?
• Can you successfully delete all files from the disk? Then add the hello world?

Simon

I think there is a problem with the mbed trying to load new programs and the reset button becoming unresponsive. I have been working with mbed for a while now and know how it reacts but it started to become stuck and unable to reset.

• Is the disk full? No, I have reformatted many times just in case.
• Can you successfully copy a program on to the disk (so when you unplug and replug, it is still there? Yes it is still there.
• What OS are you on, and have you tried a different PC? Yes, Win7+WinXp
• Can you successfully delete all files from the disk? Then add the hello world? Yes

I've had some weird problems with voltage drop. Once the device causing the drop was disconnected I think I had to reformat the MBED filesystem as it was corrupt but after clearing it things returned to normal.

Edit: Yeah definitely check the MBED with a good 5v supply, if you're relying on USB 5v then try formatting the MBED with no connected peripherals. My problems were principally because of the display modules I'm using, which are pushing the limits of "legal" USB power.