Hi

I have a problem with prototyping board that is based on LPC1768. Little description what is in 'ecosystem':

- its using SPI for SDHC card (SDHCFileSystem lib) - several serials (MODSERIAL lib) - USB in Mass Storage Mode (USBFileSystem lib) - GPS (nmea parser) - Bluetooth (on modserial ...)

Thing is not everything seems to work like on mBed. Since 2 days while program has growing up I've added modification and target board has stopped working. Flashing is working fine. But on startup there is no life activity (first thing is to light one led its first line after main() for bug checking). I'ce been fighing with lots issues like problem with USBFileSystem read usb-stick problem with production board(that have been solved by removing WFI() line from USBHostLite implementation).But anyway...question is there something that can block program from executing just on beginning when its not running on mBed.

On mBed same program working flawlessly (only difference is ports mapping).

any components (SD card, other connections has been checked and working fine).

Does anybody ever found something similar?

Please help!

If you post the code, we might be able to help.

Lerche

Im sorry, here it is:

http://mbed.org/users/sorgenskammer/code/SIPS_v2/

Is i possible to found what is blocking program from running on target? it not a hard-fault because this program is detecting that(i guess).

Sometimes when Im block some code (in main) by put while(1) its live and i can see lighten LED. but why? this is strange behavior. because all working fine when i swich to board powered by mbed.

Well I have had once something similar. If in the constructor of one of your objects it tries to communicate with for example some sensor, and that communication blocks indefinitely, your code will never arrive at your main program. I have had that happen at an I2C port without pull ups, but it can also happen if you read something from a serial port, when nothing is send it will block indefinitely.

Eric,Thanks for you answer. Unfortunately I don't believe that hardware issue is causing that. My mbed prototype is 1:1 with production board. There is no blocking code that may cause that. Everything seems to working fine unless I starred to add more funcionality. In example using function to list dir on sd/ USB ( in some object locaced far away in some class)interface cause that program is stuck just on beginning on non mbed environment, on mbed same code is fine. Then just comment this one particular line and everything back to normal. What is going on? How to trace what is happening with target?

OK, maybee in this way. Lets say my program looks like this:

main(){
LED=1;
obj1 *o1 = new obj1();
LED=2;
obj2 *o2 = new obj2();

 while(1){
 function();
 }
}

Simple program. I have found some issue that for some reason,somewhere in a part where obj2 is created something is happen and after flash by isp (flashmagic) and reset board no light is on.

On mbed board same thig is working leds are on program continuing.

if i will make something like this (add while after on LED2):

main(){
LED=1;
obj1 *o1 = new obj1();
LED=2;
while(1);
obj2 *o2 = new obj2();

 while(1){
 function();
 }
}

I can see LED1 and LED2 on. My question is why it happen? I assume if some parts a code contains a leak or any other problems not detected by compiler. It should go to that moment and then stops.

This is only example. I have found also when I use certain functions. That was working before adding some features to my program: like drectory listing 'opendir' fro FATFileSystem library whenever lets say in function() in my example reffering to opendir function it causes same problem i described before. Help please I'm desperate:) Why its working always when I use same program on mbed board. ?

Just a thought: you say you use flashmagic to download the code to your own lpc1768 board. That means that you have to convert the .bin code produced by the mbed online compiler into a .hex file for mbed. Earlier post reported problems with the bin2hex conversion utilities that people used. Some have bugs and can not deal with larger codesizes. This leads to random crashes of code that runs fine on mbed.

See http://mbed.org/forum/electronics/topic/3291/?page=3#comment-18103

That's was it! Thank you very very much. Indeed that was problem with that tool. You made my day:)