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

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...@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 )

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