Sign in

username:

password:



Not a member?

Search c54x



Search tips

Subscribe to c54x



c54x by Keywords

5409 | 5416 | AD5 | ADC | BIOS | Boot | Booting | Bootloader | C540 | C5402 | C5409 | C5416 | CCS | Codec | DMA | Dmad | DSK | DSKPlus | Dsplib | EVM | FFT | FIR | Flash | GPIO | HPI | Initialization | Interrupt | JTAG | LOG_printf | MCBSP | RFFT | RTDX | Sampling | STLM | UART | VC540

Ads

Discussion Groups

Discussion Groups | TMS320C54x | Re: Problem in CCS

Technical discussions about the TI C54x DSPs (including the c5401, c5402, c5402a, c5404, c5407, c5409, c5409a, c5410, c5410a, c5416, c5420, c5421, c5441, c549, c5470 and c5471).

  

Post a new Thread

Re: Problem in CCS - Jeff Brower - Jul 2 22:35:56 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...@yahoogroups.com, "Jeff Brower" <jbrower@...> 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...@yahoogroups.com, Jeff Brower <jbrower@> 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.
> >



(You need to be a member of c54x -- send a blank email to c54x-subscribe@yahoogroups.com )

Re: Problem in CCS - vijay_asm - Jul 4 13:54:09 2007

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...@yahoogroups.com, Jeff Brower <jbrower@...> 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...@yahoogroups.com, "Jeff Brower" <jbrower@> 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...@yahoogroups.com, Jeff Brower <jbrower@> 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.
> >



(You need to be a member of c54x -- send a blank email to c54x-subscribe@yahoogroups.com )