Doesnt look like it from your description, but do you make any calls to the magic IF chip. For example by using the ethernet lib or sleep methods. This will cause the lpc1768 on your production board to hang. Could also be issue with bin2hex conversion. Flashmagic needs hex files. I suppose you convert a bin file to hex. Search the mbed site. There are problems with some bin2hex utilities for large bin files which you will get when you include the full mbed lib.

I don't use any of the ethernet or sleep methods but I do use some methods to declare serial communications, digital controls, and I2C ports. I am using the hex file that uVision creates, but I have tried to use a bin2hex command line converter to create the hex file from the uVision bin file and it doesn't match the uVision hex file at all and does not work either.

Can you develop a minimal main.c (just toggling an output) using mbed libs and mbed compiler, then convert the bin to hex and download to your productionboard with flashmagic. Is code running as expected?

Do you declare an I2C object using the mbed lib in your uVision minimal main.c testproject? Do you use pull-up resistors on the I2C bus of your productionboard. The mbed code will hang with missing resistors.

Can you publish the minimal main.c. Can you execute the uVision bin on a regular mbed hardware board.

I have developed the minimal main.c that toggles three digital outputs that are connected to the GPIO ports and uses the mbed library. I can not find a converter that does bin to hex with proper addressing. The Keil compiler gives a data length of 1 while (which is correct) but the standard BIN2HEX gives a data length of 2 so the process of creating a bin file and using BIN2HEX to create the hex file does not work. The bin files work on the development boards. Yes, there are pull up resistors on the I2C lines.

See here for bin2hex utility links http://mbed.org/users/chris/notebook/prototype-to-hardware/

I dont understand 'data length of 1'. No real application with have a length of 1 byte ... Different bin2hex utilities can generate different length files from the same bin. They can both still be correct. That is because a hex file is in fact a text file with some possible variations in structure. You should be able to open a hex file with any text editor and at least inspect the structure.

So in Intel hex format the second and third 4 bits marks the length of the data array. When I said a data length of 1 what I meant was the data length field has 0x10 in it meaning a 16 byte data field. When I said a data length of 2 what I meant was the data length field has 0x20 in it meaning a 32 byte data field.