Watchdog prevents program load on LM3S device

Ian Cathey said:

I have a customer using an LM3S5C51 device and is having trouble loading their program using CCS. The program load fails every time due to the watchdog triggering a reset before it finishes

Ian,

Could you please provide a bit more detail to help us understand and maybe reproduce the problem.

- What error, if any, do they get from CCS? A screenshot could be helpful here.
- How are they connecting to the board - which emulator?
- Do stand-alone flash operations work? For instance, if you launch a debug session (not click on the "Debug" button), and go to the On-Chip Flash view, are you able to perform an Erase operation without problems?
- Can they generate debug server logs and attach it here? This page tell you where/how to enable these logs:
http://processors.wiki.ti.com/index.php/Troubleshooting_CCSv5#CCS_Diagnostic_Logs

The fact that they don't have problems with LM Flash programmer is a good data point. We should be able to investigate this if we are able to get additional logs or reproduce it locally (for which we would need to have a board with this device, which I'd have to ask around for).

1. The error:

2. Stellaris ICDI board, the same one that shipped in the LM3S9B92 evaluation kit

3. I've created a debug session that is set to load symbols only. That was the only way I could think of to start a debug session without attempting to load code. If there is a more straightforward route, let me know. I went to the On-Chip Flash view after starting this debug session, issued a mass erase, and got this output

CORTEX_M3_0: GEL Output:

Memory Map Initialization Complete

CORTEX_M3_0: Erasing Flash memory...

CORTEX_M3_0: Performing Mass Erase on Flash memory

CORTEX_M3_0: Operation completed successfully.

I was encouraged by the fact that the current draw went to nearly nothing after this happened (which tends to mean the processor is back to a barren state). After this, I went through the Load menu, told it to load the program, and it worked fine.

I've narrowed the difference between the two debug profiles down to whether the configuration is set to "Load program" or "load symbols only". If it's set to load symbols only and I do a manual erase, it actually erases and shuts down the processor and then manually loading the program works fine. If it's set to load program, there does not appear to be any erase/shutdown, although the console will say that it is doing so.

I have both set to "Reset target during program load to flash memory", the same erase options, but the main debug configuration does not actually seem to do it. With this separate debug configuration where I have it set to load symbols only, I can do this manual erase and then load. Why does it not actually erase/shut down the processor when the debug configuration is set to "Load program"?

4. Here is the log I collected

https://www.dropbox.com/s/4hli0hs07bzj5zx/ccsdebugserver.log.zip

You will see at line 198120 is the point at which it tried to write flash memory the last. Line 246925 is where it reports the timeout.

In the On-chip Flash, what are your settings for "Program Load-Erase Method"? The default is set to "Necessary Pages only" which means that only necessary pages will be erased not a mass erase. You could try changing it to "Use the Erase options Specified Below" and under "Erase" leave it to "Entire Flash". This should erase the entire flash each time before loading the program. This will slow down the loading process but at least we can confirm if it goes through without errors.

Also just FYI as far as launching a debug session without loading code, you don't have to actually create a debug configuration that is set to load symbols only. An alternate way is to simply launch the target configuration, then connect to target and then load program manually (and optionally perform on-chip flash operations before loading program). To launch the target configuration, open the Target Configuration view in the CCS Edit perspective, expand the Projects view to your project. Within it select the .ccxml file, right-click on it and choose "Lauch Selected Configuration". This will just launch the debugger and do nothing else. From there you can connect to target and then load program.  You can look at it as a manual/step-by-step way of performing what the green bug icon (Debug project) does for you automatically.

Let us know if modifying the flash erase properties helps or not.

Also not sure if I confirmed this before. Is the version of CCS being used v5.4?

Aarti,

We tried the settings described in your first paragraph already to no avail. I will have him try again but he has tried it once before. I will check on his CCS version now.

Any other ideas?

Thanks,

Ian

Confirmed with the customer, using CCSv5.4

Aarti,

The issue is still present for the customer, any more ideas?

-Ian

Ian,

Would the customer be able to provide the .out file they are trying to program? Maybe analyzing that file may give some clues as to what the problem is.

I also noted that you previously mentioned: "On smaller code I don't think this has been a problem for them, but for this program they are using nearly all of the 512KB of Flash on the device." I take this to mean that they only have this flash programming error with certain .out files. Is that correct? Is it only one specific program or do they see this type of error with other projects/.out files as well?

And does it occur on multiple PCs (if that is possible to test out)?

Chester Gillon said:

b) CortexM3_util.gel is included by a large number of device GEL files, so any change to CortexM3_util.gel in CCS would need to be checked that doesn't break any of the device GEL files.

Looking at a sample GEL file for the M3 core of a Concerto device, f28m36p63c2_m3.gel, shows f28m36p63c2_m3.gel already has a OnPreFileLoaded function as well as loading CortexM3_util.gel. Therefore, the suggested change to CortexM3_util.gel would cause f28m36p63c2_m3.gel to fail to load due to multiple OnPreFileLoaded functions being defined.

For anyone referencing this in the future, this issue can be worked around using the gel file in the other E2E thread pointed to by Chester.

We are also currently working on adding the functionality to the default programmer to reset the WDT registers prior to loading code.