This problem appears to be similar to the thread "Problem getting to start of main on debug startup" from a couple of years ago. The issue is that I will be plugging away doing routine debugging when for absolutely no reason at all the program will fail to start -- instead of running to main it will end up on an ESTOP that appears to be in the library (i.e. the code beyond _c_int00 entry point). The actual place it gets stuck is in a loop that appears to be calling constructors from a list of constructor addresses prior to pulling the command line arguments (!) and calling to main.
The processor is an 069 running on a Control Card. I'm using CCS5.3 with the USB emulator. The hardware appears to be OK; I have a small RAM based project I can use to check it. The code base itself is too large to run out of RAM, its a port of an existing 2812 based product that is written in C++. I've checked that the watchdog is disabled before the startup code runs and there's no problem with stack headroom.
Concident with the emergence of this problem is the observation that the system clock is running at a different speed. The Control Card usually has the processor clock set to 90MHz but after this problem appeared I noticed that it was running at the default 10MHz. This is easy enough to deal with -- we'd have to put clock initialization and the like for a real product -- and it really shouldn't affect the operation of the code (because we've got to get to main to run code to reset the clock) but because it appeared at the same time as the run-to-main issue there may be a connection.
This code is running on an evaluation board which starts up with the processor running at 90MHz. The processor's clock configuration changed overnight so its running at a default 10MHz. It is easy enough to reinitialize the clock to the correct speed (we're going to have to do this for the real product) but because it was coincident with the emergence of the run-to-main issue its possible that the two are connected.
Needless to say the emergence of this problem did not coincide with any changes to the code. It was literally a case of switch off for the evening with everything working, switch on the next morning with everything malfunctioning.
Suggestions welcome....
