So, one of the really cool things about another microcontroller....which I've used because it's cheap and pretty versatile....But I won't name here.... ;) Anyway, one cool feature it has is the ability to load a program to RAM and run it from there before having to write it to ROM... The first advantage I can say here is that it gives you the chance to take the shotgun programming approach and load, tweak, load, tweak... without wearing out the EEPROM from excessive writing, etc... (A feature that's fairly nice for those of us without a lot of experience....) =)

Anyway, just a thought... Not even sure if its feasible on the mbed.. But it'd be really cool!! =)

mbed doesn't have EEPROM, it uses flash. To reach the minimum 10000 cycles endurance you would have to flash it 20 times a day for 500 days.

That said, running you program from RAM for debugging is standard feature in most development environments for ARM. However, it requires a direct JTAG connection to the chip, and mbed doesn't have one :(

You could write a USB-Serial bootloader which downloads the program to RAM, but then it would be difficult to use the online compiler (relocation needed?)

Does anybody have experience of what the typical Flash endurance is? Has anybody "worn out" their mbed yet?

Does the mbed Interface chip keep a tally of how many times it has Flashed the LPC1768? If so, is it possible to retrieve this count?

For the FLASH chip onboard the mbed (the storage seen from the USB cable): 100,000 Program/Erase Cycles Per Page Minimum (Atmel datasheet) and for the inbuilt Flash of the CPU: Nendu endurance min 10000 typical 100000 - cycles (NXP datasheet)

Thanks for the replies! Sorry for the EEPROM/FLASH confusion, guess I should read and pay attention more.. ;)

A RAM bootloader sounds pretty attractive, but not being able to use the online compiler doesn't as much.. =/ At least to me since I move from computer to computer a lot.. How about a bootloader that receives the .bin via serial (either something like xmodem or even the compiler and copies it to an external i2c device or whatever and then loads whatever's there? I'd rather wear out an external EEPROM than the onboard flash... Then you could flash the final version when your done with the insanity..(I feel my way through the dark sometimes, which leads to a lot of flashing..especially when drawing stuff on an lcd and making sure it's in the right spot..bad practice I know...)

It would be cool to have a tally of the number of flashes.. but since that's a file copy for the most part performed by the host os..... =/ Maybe the compiler could keep count of how many times you've compiled each program successfully...!!

I have an mbed that the flash has failed, which I am in the process of removing from a board to send back to the nice mbed people...I'm not sure if I wore it out really... But it sure acts that way. But it sure hurts my heart to see a perfectly good mbed just become a zombie...when it seems there's something we could do to stop the madness! =) Honestly, I'm not sure how many people have been affected this way, but time marches on..I mean, I've still got some micros that I bought probably 6 years ago that are still as good as when I bought them...

Before mbed I used to program a lot on the DS5000 from Dallas, it is a 8051 compatible CPU connected to 32k battery backed SRAM and a serial bootloader. You could partition the 32k in seperate blocks of 'rom' and ram space and reprogram them literally endless. I still have a whole bunch of them mounted on 30 pin SIM modules including RTC, modem (!) and a DTMF decoder.

Anyway, I am a shotgun approach programmer myself and my mbed is reprogrammed already more times than I can count. Still working OK.

I like the idea of loading it into RAM instead of FLASH, except that RAM is a lot smaller & the problems with relocatable code.

I have a similar concern about the endurance of our FLASH. What if this little board ends up in a small-scale product? If it were in a larger scale product, we would want to protect our code & would not want it to be reflashed every time power-up or reset happened. 10,000 minimum cycles can add up quickly in some products.

Currently: When the mbed bootloader resets, it looks for files in the 2Meg drive. It selects the most recent *.bin file date, loads it into internal 512k FLASH and executes it. I believe it does this everytime it resets, using up the internal 512k FLASH endurance cycles. If no file is found in the 2Meg drive, the bootloader does not do anything we can see. The previous program that may have been loaded to the 512k FLASH is not executed.

Current FW Ver 141212 Loader 11972

Suggestion:

1. When the mbed bootloader resets, have it load the most recent *.bin from the 2Meg drive (as it does now).

2. User deletes the bin file from the 2Meg drive.

3. Upon reset, if there are no bin files in the 2Meg drive, execute the possible previous internal 512k bin. It won't require reflashing. It is also deeper inside the board and somewhat harder to access by hackers.

4. If we drag & drop a new file onto the 2Meg drive, have the bootloader erase the internal bin and replace it with the new one found in the 2Meg drive.

5. Give us a process to use the program protection system that the chip already has.

Wha-da-ya think?

-LarryB

As far as I know the mbed does not write the .bin file every time it starts up, it only writes it if it finds a changed bin file.

You can clearly notice the difference in startuptime if you upload a new file and reset or simply reset without uploading. When changed the mbed takes a second or two to start up, without change it starts up immediately.

So no 'wear of the flash' if you have not changed the bin file.