I have been working on porting Jumentum-SOC (http://jumentum.sourceforge.net/) to the mbed and I have it working more-or-less on the bare LPC1768.  I am using Codesourcery GCC and CMSIS for the bare metal port.

A couple of issues crop up on the mbed though.  One is the flash memory.  I use the IAP to store programs in the LPC1768 flash.  Each time I reload a new ".bin" file to test my code, the IAP data has been erased.  I tried the following I found in an IAP example on this web site:

#define USER_FLASH_AREA_START 0x20000
#define USER_FLASH_AREA_END 0x80000
#define USER_FLASH_AREA_SIZE (USER_FLASH_AREA_END-USER_FLASH_AREA_START)
#define     USER_FLASH_AREA_START_STR( x )      STR( x )
#define     STR( x )                            #x
unsigned char user_area[ USER_FLASH_AREA_SIZE ] __attribute__((section( ".ARM.__at_" USER_FLASH_AREA_START_STR( USER_FLASH_AREA_START ) ), zero_init));

However, it attempts to place the user_area into the RAM segment, which is undesirable.  Is there a way in the linker script to create a segment for the user flash memory so that the boot loader code on the mbed LPC1768 will not erase the entire flash?

A further issue I have is with the serial USB emulation.  It seems that the latency in the USB serial emulation is quite large, 100 ms or more.  This means that if the computer sends a large chunk of data via serial to the mbed, and the program on the mbed turns off flow control (XOFF) and is not able to accept it (e.g. because it is programming flash and interrupts are disabled), then the data is lost because too much data has already been sent before the flow control signal is received.  When there is no latency, the flow control signal is responded to immediately and the data flow stops before too much data is sent.  I suppose I could greatly increase the buffers and wait time before initiating flash write, but I thought there might be a different solution if I knew a little more about the mbed hardware.

Thanks,

Dan