DSPRelated.com
Forums

Re: Re: Problem in CCS

Started by Jeff Brower July 4, 2007
Vijay-

> didnt even watch the 'To' dropbox! for last 2 times....apologies for that.
>
> I dont have a debugger :( (programming is thru SPI bootloader)and
> simulaur is not helpful in this matter...
>
> so i am planning to inspect the example files and thier disassembly
>
> lets see....

Your manager (or Prof) has to get you a JTAG emulator. There's no way you can be
assigned to debug DSP code without one.

And -- more important -- no one this group is going to help you unless you have a
debugger. There's just no point; would be a waste of time.

-Jeff

> --- In c..., Jeff Brower wrote:
> >
> > Vijay-
> >
> > > well the basic problem is, CCS is using the registers 0x01, 02....for
> > > passing paramaters when a C fuction is called. i confirmed this by
> > > looking at the dissasembly, after loading the code in CCS.so i thought
> > > that based on the CPL bit state[in application code] the CCS will
> > > decide what to use, stack or relative address, during compilation and
> > > create the code accordingly.
> > >
> > > i also inspected all the epilog code CCS generated, before my
> > > application code, there was no place where CCS was killing(clearing)
> > > the CPL bit of ST1. Infact there was a line which sets the bit. but
> > > for my assurance, i placed a "SSBX CPL" instruction well before in my
> > > init code. but still it produced the same code(usinf IMR,IFR for
> > > passing parameters) and interupt also didnt work[as expected], when
> > > loaded. i duno where to go further....
> >
> > First, function entry and exit code produced by CCS is identical
> whether the CPL bit
> > is set or not. It's a *hardware function* whether the DP or SP is
> used for
> > referencing parameters -- chip circuitry interprets the CPL bit as
> needed.
> >
> > Second, debugging this should be easy. Can't you step through your
> code starting
> > with the SSBX CPL instruction and find out where -- before main() --
> the CPL bit
> > gets cleared?
> >
> > Just single-step through run-time code. Ya it's tedious, but you
> got to do the work.
> >
> > -Jeff
> >
> > PS. For second time -- post to the group, not to me. If you post to
> me again, I
> > can't answer it.
> >
> >
> > > --- In c..., "Jeff Brower" wrote:
> > > >
> > > > Vijay-
> > > >
> > > > > Thanks for your help!
> > > > > If I understand right, you mean to say that
> > > > >
> > > > > 1) CCS itself will set the CPL bit during compilation so that the
> > > > > code produced, will use stack[far address] instead of
> relative[near]
> > > > > address to pass parameters
> > > >
> > > > CCS assumes the CPL bit is set when compiling C code. It won't do
> > > anything to clear CPL. See my comments below about
> > > > boot code.
> > > >
> > > > > 2) My asm code[or C Code for that matter] kills the bit[by writing
> > > > > a '0' to it]
> > > >
> > > > That is one possibility.
> > > >
> > > > > I inspected my code and found that ST1 is not written or read
> at any
> > > > > place, both in C and asm.
> > > >
> > > > At this point your understanding of what's going on is lacking. ST1
> > > may be written frequently, for example upon
> > > > return from ISRs or functions when registers are restored from the
> > > stack. You're just looking at C source code, not
> > > > at asm code generated by CCS. You're trying to figure out what the
> > > engine looks like without opening the hood.
> > > >
> > > > > In my project settings, If CPL bit is NOT set by CCS, then i may
> > > > > have to check the settings and make it right. For that, i tried to
> > > > > inspect the Build Options and found
> > > > >
> > > > > Buld Option>Compiler>Advanced>- there wew2 options out of
> which you
> > > > > can set only one
> > > > > - Use Far Calls (-mf) ( C548 and higher)
> > > > > - Use Near Calls (no -mf)
> > > > >
> > > > > and the second option was set.
> > > > >
> > > > > After building, i loaded the .out file to see what was
> happening in
> > > > > Disassembly. As expected, the functions used 0x00\01\02....for
> > > > > passing parameters. So i changed the option to "Use Far
> Calls(-mf)"
> > > > > but the linker gave following warning
> > > > >
> > > > > "linking incompatible formats: file compiled with -mf"
> > > > >
> > > > > thus, the linker forced the near calls.
> > > > >
> > > > > To put it simple, is this [ Use Far Calls (-mf) ] the right way to
> > > > > set CPL? If not, what is teh right way?
> > > >
> > > > The Far Call setting doesn't have do with the CPL bit, it has to do
> > > with calling code outside the 64k byte range; i.e.
> > > > code in "extended program page' memory. Consult the C54x data sheet
> > > to learn more abour far memory.
> > > >
> > > > How does your code boot? You have to track down the boot code and
> > > go from there. When the C54x boots, it must set
> > > > various registers including status registers (ST0, ST1), stack
> > > pointer, etc. At some point CPL is either set or
> > > > cleared. If it's set, then you need to do low-level debugging until
> > > you find out where it got cleared.
> > > >
> > > > -Jeff
> > > >
> > > > PS. Please post to the group, not to me.
> > > >
> > > >
> > > > > --- In c..., Jeff Brower wrote:
> > > > >>
> > > > >> Vijay-
> > > > >>
> > > > >> > I work on 5402 dsp and face a strange problem in CCS(ver 3.1).
> > > > > That
> > > > >> > was a old project which never used interrupts. Both C and asm
> > > > > files
> > > > >> > are there. C for main\algorithm\logic and asm for low level
> > > > > drivers.
> > > > >> > No interupt was used in that project.
> > > > >> >
> > > > >> > Now i want to add a timer interrupt and came to know [thru
> > > > > Simulator]
> > > > >> > that when a C funtion is called with parameters, CCS uses
> memory
> > > > >> > location 0x00, 0x01, 0x02 respectively, to pass parameters,
> > > > > instead
> > > > >> > of stack And now they are eventually interrupt registers
> > > > >> >
> > > > >> > 0x00 - IMR
> > > > >> > 0x01 - IFR
> > > > >> >
> > > > >> > So the interrupt never worked!
> > > > >> >
> > > > >> > i read somewehere that CCs uses STack and not these addresses
> > > > > but in
> > > > >> > reality its using these memlocs to pass parameters...
> > > > >> > whats the way to make CCS to use stack?
> > > > >> > how to avoid CCS from corrupting interupt Registers....
> > > > >> >
> > > > >> > Bhooshan and other Experts, help me!!
> > > > >>
> > > > >> Somehow you have not set the CPL bit in ST1 register. CCS
> > > > > normally sets this bit
> > > > >> when generating code, but I'm guessing you have some asm code
> > > > > somewhere that kills
> > > > >> the bit.
> > > > >>
> > > > >> Look in the C54x CPU Reference Guide for more information on the
> > > > > CPL bit:
> > > > >>
> > > > >> http://focus.ti.com/lit/ug/spru131g/spru131g.pdf
> > > > >>
> > > > >> -Jeff
> > > > >>
> > > > >> PS. I changed the group addr to be c54x, not c6x.
> > > > >>
> > > > >
> > > > >
> > > > > Somehow you have not set the CPL bit in ST1 register.
> > > > > CCS normally sets this bit when generating code,
> > > > > but I'm guessing you have some asm code somewhere that kills
> the bit.
> > > > >
> > > > > Look in the C54x CPU Reference Guide for more information on
> the CPL
> > > > > bit
> > > > >
> > > > > focus.ti.comlitugspru131gspru131g.pdf
> > > > >
> > > > > -Jeff
> > > > >
> > > > > PS. I changed the group addr to be c54x, not c6x.
why you need a debugger to test this problem???? instead of knowing
where(in the prolog\epilog code) the CPL bit is cleared, set it right
before calling a function, in your code....

i did that and still the same code got generated......the problem is
in code generation and not in run time. so i am again going thru the
CCS Build Options and related documentations. meanwhile i hav put this
issue to the Local TI support here....totally clueless :(

anyway i am aware that a debugger is a MUST in most cases

--- In c..., Jeff Brower wrote:
>
> Vijay-
>
> > didnt even watch the 'To' dropbox! for last 2 times....apologies
for that.
> >
> > I dont have a debugger :( (programming is thru SPI bootloader)and
> > simulaur is not helpful in this matter...
> >
> > so i am planning to inspect the example files and thier disassembly
> >
> > lets see....
>
> Your manager (or Prof) has to get you a JTAG emulator. There's no
way you can be
> assigned to debug DSP code without one.
>
> And -- more important -- no one this group is going to help you
unless you have a
> debugger. There's just no point; would be a waste of time.
>
> -Jeff
>
> > --- In c..., Jeff Brower wrote:
> > >
> > > Vijay-
> > >
> > > > well the basic problem is, CCS is using the registers 0x01,
02....for
> > > > passing paramaters when a C fuction is called. i confirmed this by
> > > > looking at the dissasembly, after loading the code in CCS.so i
thought
> > > > that based on the CPL bit state[in application code] the CCS will
> > > > decide what to use, stack or relative address, during
compilation and
> > > > create the code accordingly.
> > > >
> > > > i also inspected all the epilog code CCS generated, before my
> > > > application code, there was no place where CCS was
killing(clearing)
> > > > the CPL bit of ST1. Infact there was a line which sets the
bit. but
> > > > for my assurance, i placed a "SSBX CPL" instruction well
before in my
> > > > init code. but still it produced the same code(usinf IMR,IFR for
> > > > passing parameters) and interupt also didnt work[as expected],
when
> > > > loaded. i duno where to go further....
> > >
> > > First, function entry and exit code produced by CCS is identical
> > whether the CPL bit
> > > is set or not. It's a *hardware function* whether the DP or SP is
> > used for
> > > referencing parameters -- chip circuitry interprets the CPL bit as
> > needed.
> > >
> > > Second, debugging this should be easy. Can't you step through your
> > code starting
> > > with the SSBX CPL instruction and find out where -- before main() --
> > the CPL bit
> > > gets cleared?
> > >
> > > Just single-step through run-time code. Ya it's tedious, but you
> > got to do the work.
> > >
> > > -Jeff
> > >
> > > PS. For second time -- post to the group, not to me. If you post to
> > me again, I
> > > can't answer it.
> > >
> > >
> > > > --- In c..., "Jeff Brower" wrote:
> > > > >
> > > > > Vijay-
> > > > >
> > > > > > Thanks for your help!
> > > > > > If I understand right, you mean to say that
> > > > > >
> > > > > > 1) CCS itself will set the CPL bit during compilation so
that the
> > > > > > code produced, will use stack[far address] instead of
> > relative[near]
> > > > > > address to pass parameters
> > > > >
> > > > > CCS assumes the CPL bit is set when compiling C code. It
won't do
> > > > anything to clear CPL. See my comments below about
> > > > > boot code.
> > > > >
> > > > > > 2) My asm code[or C Code for that matter] kills the bit[by
writing
> > > > > > a '0' to it]
> > > > >
> > > > > That is one possibility.
> > > > >
> > > > > > I inspected my code and found that ST1 is not written or read
> > at any
> > > > > > place, both in C and asm.
> > > > >
> > > > > At this point your understanding of what's going on is
lacking. ST1
> > > > may be written frequently, for example upon
> > > > > return from ISRs or functions when registers are restored
from the
> > > > stack. You're just looking at C source code, not
> > > > > at asm code generated by CCS. You're trying to figure out
what the
> > > > engine looks like without opening the hood.
> > > > >
> > > > > > In my project settings, If CPL bit is NOT set by CCS, then
i may
> > > > > > have to check the settings and make it right. For that, i
tried to
> > > > > > inspect the Build Options and found
> > > > > >
> > > > > > Buld Option>Compiler>Advanced>- there wew2 options out of
> > which you
> > > > > > can set only one
> > > > > > - Use Far Calls (-mf) ( C548 and higher)
> > > > > > - Use Near Calls (no -mf)
> > > > > >
> > > > > > and the second option was set.
> > > > > >
> > > > > > After building, i loaded the .out file to see what was
> > happening in
> > > > > > Disassembly. As expected, the functions used 0x00\01\02....for
> > > > > > passing parameters. So i changed the option to "Use Far
> > Calls(-mf)"
> > > > > > but the linker gave following warning
> > > > > >
> > > > > > "linking incompatible formats: file compiled with -mf"
> > > > > >
> > > > > > thus, the linker forced the near calls.
> > > > > >
> > > > > > To put it simple, is this [ Use Far Calls (-mf) ] the
right way to
> > > > > > set CPL? If not, what is teh right way?
> > > > >
> > > > > The Far Call setting doesn't have do with the CPL bit, it
has to do
> > > > with calling code outside the 64k byte range; i.e.
> > > > > code in "extended program page' memory. Consult the C54x
data sheet
> > > > to learn more abour far memory.
> > > > >
> > > > > How does your code boot? You have to track down the boot
code and
> > > > go from there. When the C54x boots, it must set
> > > > > various registers including status registers (ST0, ST1), stack
> > > > pointer, etc. At some point CPL is either set or
> > > > > cleared. If it's set, then you need to do low-level
debugging until
> > > > you find out where it got cleared.
> > > > >
> > > > > -Jeff
> > > > >
> > > > > PS. Please post to the group, not to me.
> > > > >
> > > > >
> > > > > > --- In c..., Jeff Brower wrote:
> > > > > >>
> > > > > >> Vijay-
> > > > > >>
> > > > > >> > I work on 5402 dsp and face a strange problem in
CCS(ver 3.1).
> > > > > > That
> > > > > >> > was a old project which never used interrupts. Both C
and asm
> > > > > > files
> > > > > >> > are there. C for main\algorithm\logic and asm for low level
> > > > > > drivers.
> > > > > >> > No interupt was used in that project.
> > > > > >> >
> > > > > >> > Now i want to add a timer interrupt and came to know [thru
> > > > > > Simulator]
> > > > > >> > that when a C funtion is called with parameters, CCS uses
> > memory
> > > > > >> > location 0x00, 0x01, 0x02 respectively, to pass parameters,
> > > > > > instead
> > > > > >> > of stack And now they are eventually interrupt registers
> > > > > >> >
> > > > > >> > 0x00 - IMR
> > > > > >> > 0x01 - IFR
> > > > > >> >
> > > > > >> > So the interrupt never worked!
> > > > > >> >
> > > > > >> > i read somewehere that CCs uses STack and not these
addresses
> > > > > > but in
> > > > > >> > reality its using these memlocs to pass parameters...
> > > > > >> > whats the way to make CCS to use stack?
> > > > > >> > how to avoid CCS from corrupting interupt Registers....
> > > > > >> >
> > > > > >> > Bhooshan and other Experts, help me!!
> > > > > >>
> > > > > >> Somehow you have not set the CPL bit in ST1 register. CCS
> > > > > > normally sets this bit
> > > > > >> when generating code, but I'm guessing you have some asm code
> > > > > > somewhere that kills
> > > > > >> the bit.
> > > > > >>
> > > > > >> Look in the C54x CPU Reference Guide for more information
on the
> > > > > > CPL bit:
> > > > > >>
> > > > > >> http://focus.ti.com/lit/ug/spru131g/spru131g.pdf
> > > > > >>
> > > > > >> -Jeff
> > > > > >>
> > > > > >> PS. I changed the group addr to be c54x, not c6x.
> > > > > >>
> > > > > >
> > > > > >
> > > > > > Somehow you have not set the CPL bit in ST1 register.
> > > > > > CCS normally sets this bit when generating code,
> > > > > > but I'm guessing you have some asm code somewhere that kills
> > the bit.
> > > > > >
> > > > > > Look in the C54x CPU Reference Guide for more information on
> > the CPL
> > > > > > bit
> > > > > >
> > > > > > focus.ti.comlitugspru131gspru131g.pdf
> > > > > >
> > > > > > -Jeff
> > > > > >
> > > > > > PS. I changed the group addr to be c54x, not c6x.
>