C6747 CCS Watch Window / Breakpoint Problem

What variables are you looking at?  There could still be another peripheral running even when the emulation is halted.  A good example is EDMA.  After the EDMA is set to continuously run, it will continue running irrespective to the behavior of the core. 

In most peripherals, there is a FREE/SOFT emulation field in the control register.  Make sure that the key peripherals you are inspecting has the field set to halt whenever emulation stops. 

Also, you should check the SUSPSRC register in the SYSCFG module.  Make sure that emulation suspend source is the DSP and not ARM.  If the emulation suspend source is the ARM and it's free running, a halt in the DSP will not cause the peripheral to suspend. 

--Christina

You could also be in real-time mode and that could explain some variables getting updated while halted. 

John,

John Wilkes said:

However, if I click on a value in the watch window, randomly, some other watched variables in the window change value (and go red). If I click again, some more randomly change. The processor is still halted on the same instruction, but variable values appear to be changing! Is it a bug? Or some weird consequence of using cached memory?

I have experienced this if the variables (not code) are stored in external memory (SDRAM) and the memory controller (EMIF) is not properly configured. In this case any memory reads return random values. To check this, open a memory view (menu View --> Memory) and point to an address in external memory (0x80000000 if I am not mistaken). If you update the view and see ever changing values, the EMIF timings are misconfigured. This is fixed by adding the proper GEL file to the target configuration. Check the pages below for obtaining the files and adding them to your configuration.

GEL files:

http://support.spectrumdigital.com/boards/evmomapl137/revg/

Adding them to the configuration:

http://processors.wiki.ti.com/index.php/GSG:Adding_GEL_files_to_a_target_configuration

Hope this helps,

Rafael

Thank you all for your help and suggestions. I have responded to the comments in this single post:

Christina:

I am looking at local variables in the function in which the  processor has stopped on a breakpoint. I have not set up any EDMA so I assume this is not running. Indeed, I am not using any of the peripherals other than GPIO. I checked the SUSPSRC register and it is all F’s which I believe means that the DSP is in control of the suspend signal. The ARM core is being held in reset.

Ki-Soo:

I have not enabled real time mode (I wouldn’t know how) so I don’t think it is active (is there any easy check to see if it is?) and anyway, this data is in internal memory with all peripherals disabled – so nothing should be changing it anyway!

Rafael:

The data is in L2 RAM (configured as internal memory, not cache). The actual address range (as reported in the CCS watch window) is 0x1180E180 through 0x1180E1E0 (two 6 element, double arrays). Do your memory timings comment still apply to internal RAM?

Actually, here is something weird: since these are local variables I expect them to be on the stack, right? Well, according to the dot map file that is generated at compilation, the stack starts at 0x1180E1B0 and is 0x400 in length. Only one of my variables appears to be on the stack!! the other (at 0x1180E180) is in memory that the MAP file says is assigned to the '.far' section (specifically the .far sections from bios.a674 and rts6740.lib). Any clues as to what is going on here?

Thanks again.

Cheers,

John.