The watchdog is possibly being enabled during the boot code.
In any case, your code, as a common practice, should initialize the watchdog,
the PLL, the RAM wait states, the FLASH wait states, the FLASH pipelining, the
code/locking key area, etc. (the actual list of things to initialize depends on
the features of the 6486 DSP.)
A good idea would be to run your code to 'main()'
then check the state of the watchdog (enabled/disabled)
(most debug work is done with the watchdog disabled)
Also check the state of the 'global interrupt enable', etc
(at the beginning of main(), all interrupts should all be disabled)
each of the interrupt events/code exceptions should have some kind of
If you look at the interrupt vector table contents,
you can determine how each interrupt/exception is being handled; as their may be
default code in them to cause the DSP to reset.
One thing that can be done, to determine if the watchdog is causing the reset,
--run to main
--step a few steps into main
--set a breakpoint at main
shortly after the reset occurs, the code will stop at main and you can examine
the system and watchdog registers to determine if the cause of the reset was the
You should also, at the same time, set a breakpoint at address 0.
Code that is trying to execute a function via a pointer, when the function is
missing or the pointer contains 0, will try to execute at address 0.
Another excellent debug tool is to fill all unused flash/ram with the 'halt'
This can be done via several methods, including:
--using the 'fill' parameter in the .cmd file
--filling all ram/flash using the CCS before loading the program.
--modifying the boot code to perform the setting of RAM, before copying the
'initialized ram' sections from flash to ram.
If your code contains assembly functions, you can check the value of the stack
pointer, step through the assembly function, then check that the value of the
stack is back to its' (before the call to the assembly function) original
It makes it much easier to debug the code if the 'debug' parameter is used and
no optimization parameters during the code compile and link processes.
In the end, you have two choices, debug the problem your self, given the little
hints/help we can offer -or- post the source code and .cmd file so we can see
what is actually happening in the code.
You mentioned that all the cores stop when a breakpoint is encountered.
It will be MUCH MUCH easier for you if only one core is actually running and the
others are halted or in a small 'forever' loop.
This is because a different core, running different code, may be corrupting the
code and/or data for the core you are working with.
---------- Original Message -----------
From: Arun Kumar Shukla
To: Richard Williams
Sent: Mon, 11 Jan 2010 17:23:36 +0530
Subject: Re: [c6x] TCI6486 reset problem
> Hi Rechard,
> Thanks for reply.
> Actually things are like this:
> (1) I have not enabled the watchdog.
> (2) I am running the code in 6486's EVAL board and using CCS3.3.
> is it possible that any exception can cause reset(some code corruptions)?
> Arun Kumar Shukla
> On Sat, Jan 9, 2010 at 11:25 PM, Richard Williams
> Regarding the reset problem...
> There are several ways the software can cause a reset.
> --watchdog is enabled, but the periodic refresh is not performed with the
required time span.
> --watchdog 'key' is written with the wrong value and/or in the wrong order.
> --a GPIO pin is attached to the external watchdog reset and/or the powerup
reset line. (not too likely, but possible)
> I would look first at the watchdog enabled, but not being refreshed often
> regarding the breakpoint stopping all cores...
> I think: CCS version 4.0 is needed to be able to stop only one core via a
> If running CCS 4.0, then to have a breakpoint only go to the 'current'/active
core, then 'Enable Synchronous Mode' button in the 'Debug' view must not be
> R. Williams
> ---------- Original Message -----------
> From: Arun Kumar Shukla
> To: c...
> Sent: Sat, 9 Jan 2010 17:26:00 +0530
> Subject: [c6x] TCI6486 reset problem
> > Hi,
> > Problem 1:
> > I am using TI 6486 muti core dsp. When i am running the code from CCS, some
times a face a problem that DSP gets reset.
> > In that case i am not able to debug the problem as lost all the register
> > Any other alternative to debug this kind of problem. I want to know that are
the conditions in which dsp gets reset.
> > Problem 2:
> > If i am adding a break point at any address of core then other cores are
also halted at same address.
> > is it possible to add breakpoint only for a particular core.
> > Thanks,
> > Arun Kumar Shukla
> ------- End of Original Message -------
------- End of Original Message -------