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
values etc.
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
TCI6486 reset problem
Started by ●January 9, 2010
Reply by ●January 10, 20102010-01-10
Arun,
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 enough.
regarding the breakpoint stopping all cores...
I think: CCS version 4.0 is needed to be able to stop only one core via a breakpoint.
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 enabled.
R. Williams
I
---------- 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 values etc.
> 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 -------
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 enough.
regarding the breakpoint stopping all cores...
I think: CCS version 4.0 is needed to be able to stop only one core via a breakpoint.
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 enabled.
R. Williams
I
---------- 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 values etc.
> 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 -------
Reply by ●January 11, 20102010-01-11
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)?
Thanks,
Arun Kumar Shukla
On Sat, Jan 9, 2010 at 11:25 PM, Richard Williams wrote:
> Arun,
>
> 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
> enough.
>
> regarding the breakpoint stopping all cores...
> I think: CCS version 4.0 is needed to be able to stop only one core via a
> breakpoint.
> 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 enabled.
>
> R. Williams
>
> I
> *---------- 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
> values etc.
> > 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 -------*
>
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)?
Thanks,
Arun Kumar Shukla
On Sat, Jan 9, 2010 at 11:25 PM, Richard Williams wrote:
> Arun,
>
> 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
> enough.
>
> regarding the breakpoint stopping all cores...
> I think: CCS version 4.0 is needed to be able to stop only one core via a
> breakpoint.
> 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 enabled.
>
> R. Williams
>
> I
> *---------- 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
> values etc.
> > 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 -------*
>
Reply by ●January 11, 20102010-01-11
Arun,
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 'handler'.
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, is
--run to main
--step a few steps into main
--set a breakpoint at main
--run
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 watchdog.
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' instruction.
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 value.
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.
R. Williams
---------- Original Message -----------
From: Arun Kumar Shukla
To: Richard Williams
Cc: c...
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)?
>
> Thanks,
> Arun Kumar Shukla
>
> On Sat, Jan 9, 2010 at 11:25 PM, Richard Williams wrote:
>
> Arun,
>
> 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 enough.
>
> regarding the breakpoint stopping all cores...
> I think: CCS version 4.0 is needed to be able to stop only one core via a breakpoint.
> 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 enabled.
>
> R. Williams
>
> I
>
> ---------- 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 values etc.
> > 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 -------
_____________________________________
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 'handler'.
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, is
--run to main
--step a few steps into main
--set a breakpoint at main
--run
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 watchdog.
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' instruction.
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 value.
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.
R. Williams
---------- Original Message -----------
From: Arun Kumar Shukla
To: Richard Williams
Cc: c...
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)?
>
> Thanks,
> Arun Kumar Shukla
>
> On Sat, Jan 9, 2010 at 11:25 PM, Richard Williams wrote:
>
> Arun,
>
> 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 enough.
>
> regarding the breakpoint stopping all cores...
> I think: CCS version 4.0 is needed to be able to stop only one core via a breakpoint.
> 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 enabled.
>
> R. Williams
>
> I
>
> ---------- 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 values etc.
> > 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 -------
_____________________________________
