DSPRelated.com
Forums

Re: Problem in CCS

Started by Jeff Brower July 2, 2007
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.
> >
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....
--- 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.
> >