Now I have compiled code with far addressing. In between I wait for an
dma interrupt for half buffer full (through McBSP) to get data from
codec chip. to wait for that interrupt I use above function
DSP_Wait.
This works very fine when compiled for near. but, with far addressing program
crashes after calling this function. it was observed that mostly after
"idle 1" in DSP_Wait, SP(stack pointer) gets corrupted (FRET makes it
go to that location) and so often goes to some junk location.
Could you please help me to solve this problem. Any extra setting for DMA
interrupts enabling is required or what????
Ritesh
Reply by Jeff Brower●July 26, 20052005-07-26
Ritesh-
> Also I am taking care with application
In that case, where is your interrupt vector code? That could be the most
important
thing to check.
One guess is that you are not saving XPC on the stack in your interrupt vector
--
C54xx does not do it for you because the chip does not "know" your
code is running
from far memory when it gets an interrupt. If you don't save XPC, then the
FRET
instruction above will mis-align the stack, and you will crash -- badly.
You must do something like this:
McBSP_Int:
push(xpc)
far goto _DSP_Wait
nop
That's from recall so not exact, but should be close.
-Jeff
Reply by Michael Dorin●July 26, 20052005-07-26
Ritesh,
Sorry to say, I am in a hurry and did not have time
to read your email in detail, but I think I have
this jist.
Here is our plan.
We are going to have the all the isr's and the
operating system code reside in page 0.
My belief is that then the ISR's can push the
XPC onto the stack up entry and pop it just
before they do a 'regular' return.
I 'think' this should work, as changing the XPC
from page 0, the code will still be executing in
page 0.
Anybody have some thoughts on this plan? We have
not tried it as of yet.
> Hi,
> ------------------- > My gel file has below options
>
> #define PMST_VAL 0x0128u
> #define SWWSR_VAL 0x8e38u
>
> Also I am taking care with application
---------------------------------- >
> my cmd file has
>
> PAGE 0: EPROG: origin = 0x180, len = 0x3000
> VECT: origin = 0x100, len = 0x80
>
> and
> .vectors: {} > VECT PAGE 0
>
> settings for interrupt vectors
---------------------------------- >
> _DSP_Wait: nop
> nop
> idle 1 ; serial ports running
> nop
> nop
> FRET
- >
> Now I have compiled code with far addressing. In
> between I wait for an dma
> interrupt for half buffer full (through McBSP) to
> get data from *codec chip*.
> to wait for that interrupt I use above function
> DSP_Wait.
>
> This works very fine when compiled for near. but,
> with far addressing
> program crashes after calling this function. it was
> observed that mostly
> after "idle 1" in DSP_Wait, SP(stack pointer) gets
> corrupted (FRET makes it
> go to that location) and so often goes to some junk
> location.
>
> Could you please help me to solve this problem. Any
> extra setting for DMA
> interrupts enabling is required or what????
>
> Ritesh
>
Reply by Ritesh Patel●July 26, 20052005-07-26
------------------------
I call DSP_Wait from c function main only. so It will push XPC also: Below
int main()
{
// Stopping all previous things
asm(" stm #0,imr");/// Disable All interrupts
StopDma();
StopDma05();//new added
StopMcBsp1();
StopMcBsp0();
// Initialising New Things
Init5409();
asm(" rsbx xf");
Start_Timer();
DSP_Wait();
DSP_Wait();DSP_Wait();DSP_Wait();DSP_Wait();
Stop_Timer();
DmaChaPos=0;
InitDma05(CodecIn1,CodecOut1);
InitMcBsp0();
InitMcBsp1();DSP_Wait();DSP_Wait();DSP_Wait(); DSP_Wait();
----------------
My VECTOR1.asm is as below
.sect ".vectors"
.ref _c_int00 ; C entry point
.ref _Timer_ISR
.ref _Dma_Ch0_Isr ;
.ref _Dma_Ch2_Isr ;
.align 0x80 ; must be aligned on page boundary
RESET: ; reset vector
BD _c_int00
NOP
NOP ; stack size of 200
nmi: FRETE ; enable interrupts and FRETurn from one
NOP
NOP
NOP ;NMI~
hint: ;DSP interrupt from MSP
; b _DspInt_Isr
nop
nop
NOP
FRETE
dmac2:
b _Dma_Ch2_Isr
;nop
;nop
NOP
FRETE
xint1: FRETE
NOP
NOP
NOP
dma4: ;b _Dma_Ch4_Isr
nop
nop
NOP
FRETE
dma5: FRETE
NOP
NOP
NOP
.end
On 7/26/05, Jeff Brower <jbrower@jbro...> wrote: >
> Ritesh-
>
> > Also I am taking care with application
>
> In that case, where is your interrupt vector code? That could be the most
> important
> thing to check.
>
> > settings for interrupt vectors
> >
> > ----------------------------------
> >
> > _DSP_Wait: nop
> > nop
> > idle 1 ; serial ports running
> > nop
> > nop
> > FRET
>
> One guess is that you are not saving XPC on the stack in your interrupt
> vector --
> C54xx does not do it for you because the chip does not "know"
your code is
> running
> from far memory when it gets an interrupt. If you don't save XPC, then
the
> FRET
> instruction above will mis-align the stack, and you will crash -- badly.
>
> You must do something like this:
>
> McBSP_Int:
>
> push(xpc)
> far goto _DSP_Wait
> nop
>
> That's from recall so not exact, but should be close.
>
> -Jeff
>
--
Ritesh Patel
M.Tech. IIT-Bombay
Reply by Jeff Brower●July 26, 20052005-07-26
Ritesh-
> I call DSP_Wait from c function main only. so It
will push XPC also:
C code function call? Does the chip care about C code at the instant of
interrupt?
How would the chip "know" it's executing C code when it gets an
interrupt? Please
think about that.
C code is irrelevant here. Your problem is interrupt processing, at chip level.
Please read my previous mail carefully. For far mode run-time, your interrupt
vectors below are clearly incorrect. Just take time to study and compare to mine
--
u will see it.
-Jeff
> int main()
> {
>
> // Stopping all previous things
> asm(" stm #0,imr");/// Disable All interrupts
> StopDma();
> StopDma05();//new added
> StopMcBsp1();
> StopMcBsp0();
>
> // Initialising New Things
> Init5409();
> asm(" rsbx xf");
> Start_Timer();
> DSP_Wait();
> DSP_Wait();DSP_Wait();DSP_Wait();DSP_Wait();
> Stop_Timer();
> DmaChaPos=0;
> InitDma05(CodecIn1,CodecOut1);
> InitMcBsp0();
> InitMcBsp1();DSP_Wait();DSP_Wait();DSP_Wait(); DSP_Wait();
> ----------------
>
> My VECTOR1.asm is as below
>
> .sect ".vectors"
>
> .ref _c_int00 ; C entry point
> .ref _Timer_ISR
> .ref _Dma_Ch0_Isr ;
> .ref _Dma_Ch2_Isr ;
> .align 0x80 ; must be aligned on page boundary
>
> RESET: ; reset vector
> BD _c_int00
> NOP
> NOP ; stack size of 200
> nmi: FRETE ; enable interrupts and FRETurn from one
> NOP
> NOP
> NOP ;NMI~
>
> ; software interrupts
> sint17 .space 4*16
> sint18 .space 4*16
> sint19 .space 4*16
> sint20 .space 4*16
> sint21 .space 4*16
> sint22 .space 4*16
> sint23 .space 4*16
> sint24 .space 4*16
> sint25 .space 4*16
> sint26 .space 4*16
> sint27 .space 4*16
> sint28 .space 4*16
> sint29 .space 4*16
> sint30 .space 4*16
>
> int0: FRETE
> NOP
> NOP
> NOP
> int1: FRETE
> NOP
> NOP
> NOP
> int2: FRETE
> NOP
> NOP
> NOP
> tint: b _Timer_ISR;
> ; NOP
> NOP
> FRETE
> rint0: FRETE
> NOP
> NOP
> NOP
> xint0: FRETE
> NOP
> NOP
> NOP
> rint2: ; Dma Ch0 interrupt
> b _Dma_Ch0_Isr
> ;NOP
> ;NOP
> NOP
> FRETE
>
> xint2: ; Dma Ch1 interrupt
> ;b _Dma_Ch1_Isr
> nop
> nop
> NOP
> FRETE
> int3: FRETE
> NOP
> NOP
> NOP
>
> hint: ;DSP interrupt from MSP
> ; b _DspInt_Isr
> nop
> nop
> NOP
> FRETE
> dmac2:
> b _Dma_Ch2_Isr
> ;nop
> ;nop
> NOP
> FRETE
>
> xint1: FRETE
> NOP
> NOP
> NOP
>
> dma4: ;b _Dma_Ch4_Isr
> nop
> nop
> NOP
> FRETE
>
> dma5: FRETE
> NOP
> NOP
> NOP
> .end
> On 7/26/05, Jeff Brower <jbrower@jbro...> wrote:
>
> Ritesh-
>
> > Also I am taking care with application
>
> In that case, where is your interrupt vector code? That could be the
> most important
> thing to check.
>
> > settings for interrupt vectors
> >
> > ----------------------------------
> >
> > _DSP_Wait: nop
> > nop
> > idle 1 ; serial ports running
> > nop
> > nop
> > FRET
>
> One guess is that you are not saving XPC on the stack in your interrupt
> vector --
> C54xx does not do it for you because the chip does not "know"
your code
> is running
> from far memory when it gets an interrupt. If you don't save XPC,
then
> the FRET
> instruction above will mis-align the stack, and you will crash -- badly.
>
> You must do something like this:
>
> McBSP_Int:
>
> push(xpc)
> far goto _DSP_Wait
> nop
>
> That's from recall so not exact, but should be close.
>
> -Jeff
>
> --
> Ritesh Patel
> M.Tech. IIT-Bombay
>
> Name: Dma_Ch0_Isr.asm
> Dma_Ch0_Isr.asm Type: Plain Text (text/plain)
> Encoding: base64
>
> Name: Dma_Ch2_Isr.asm
> Dma_Ch2_Isr.asm Type: Plain Text (text/plain)
> Encoding: base64
Reply by Ritesh Patel●July 27, 20052005-07-27
I changed my vectors.asm like as below: and seems my application
is follows interrupts well. (someof the lines as shown below)d
One guess is that you are not saving XPC on the stack in your interrupt
vector -- C54xx does not do it for you because the chip does not
"know" your code is running
from far memory when it gets an interrupt. If you don't
save XPC, then the FRET instruction above will mis-align the stack, and you
will crash -- badly.
You must do something like this:
McBSP_Int:
push(xpc) far goto _DSP_Wait nop
That's from recall so not exact, but should be
close.
-Jeff
-- Ritesh Patel M.Tech. IIT-Bombay
Reply by Jeff Brower●July 27, 20052005-07-27
Ritesh-
> I changed my vectors.asm like as below: and seems my application
> is follows interrupts well. (someof the lines as shown below)
This looks much improved. I'm glad to hear you're making
progress.
DSP can be cool, huh.
But one thing: there is latency after FRETE, right? So the
next instruction will be executed... You may need something like
this to avoid a stack mix-up:
I thanks to Jeff for this and also tried earlier Michael's
suggestion of putting all ISRs in page 0 and replacing FRETE with RETE
(normal return). With Regards,RiteshOn 7/26/05,
Jeff Brower <j...@signalogic.com>
wrote:
Ritesh-
> Also I am taking care with application
In that case, where is your interrupt vector code? That could
be the most important
thing to check.
One guess is that you are not saving XPC on the stack in your interrupt
vector --
C54xx does not do it for you because the chip does not "know" your
code is running
from far memory when it gets an interrupt. If you don't save
XPC, then the FRET
instruction above will mis-align the stack, and you will crash -- badly.
You must do something like this:
McBSP_Int:
push(xpc)
far goto _DSP_Wait
nop
That's from recall so not exact, but should be close.
