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.
