Hi,

I am encountered a strange problem on my DSP board (Customized) using
TMS320C6211.

I am using the SDRAMs (2 Nos) each of 1Mx16x4(banks) capacity to access the
32 bit word. On my customized board the TTL output of the DSP is driven by
the Buffers to produce the 5V signal from the 3.3V signal. this Buffered
Signal is given on the 40 PIN connector from where we are extending the
Flat-Cable connector to connect the Data Bits on the other Slave Cards..
When I am not using the Connector and testing the SDRAM walk bit test of all
the locations from 0x80000000 to 0x8000FFFF then my SDRAM test is getting
pass, even if I am putting my .text section of the Code in .CMD file, then
Code is going in to the SDRAM successfully and running also, I have
configured the .GEL file for the SDRAM very properly, Each of the EMIF
registeter regarding the SDRAM I have configured long back and still I was
facing no problem in any length of the code.

Now yesterday, I put the Flat cable on the 40PIN connector and try to Run my
code of size 517KB which .text portion I routed in to the SDRAM. After Build
ALL the code is not loading in to the SDRAM, it is showing that Data
verification failed at 0x80000000 and some other locations also. Now I
removed the Slave card on the other End of the 40PIN connector and run the
Test again, Now again the same error encountered, even SDRAM walk bit test
is getting failed. the length of the Cable is around 1.5 ft (simple computer
bus flat cable). Now I tried with the shorter cable of around 6 inches. with
other end open. The test is getting pass. I tried many lenghts of cable and
observed that after 10 inches of the cable (Other end open) the SDRAM test
is getting failed.

I am providing the 75MHz clock to the SDRAM.

One other Problem is: - When I am putting any of the 32 data pin on the
40PIN connector to the Logical Grounded manualy with the help of Jumper. The
SDRAM test is getting pass. But it should get fail when I am forcefully
grounding the Data Pin to ground.

Plese Help me to get the problem solved.
On 27/12/06, Jeff Brower wrote:
>
> Michael-
>
> I would add to Sankaran's helpful comments below: the routine should
> *restore* GIE. That is, whatever state GIE is
> in when entering the routine, make things the same when leaving.
>
> If GIE is off for good reason when entering your routine and then on when
> it shouldn't be when leaving, that's another
> type of bug you would have to fight.
>
> -Jeff
>
> > a. Should the routine restore back GIE or leave it
> > disabled?
> >
> >
> >
> > The routine should restore the GIE once it has finished the multiple
> > register assignment code during the
> >
> > Software pipelined code phase, so the user should not have to do
> anything,
> > the routine manages GIE
> >
> > on its own.
> >
> >
> >
> > b. There may be a bug with the stack management code, which saves and
> > restores CSR, whose lowest bit is
> >
> > GIE. If I were you I would make sure that my CSR is getting restored
> > correctly. If the only thing wrong with
> >
> > it is that GIE is not turned o, once you exit, you can OR CSR with 0x1,
> as
> > follows CSR |= 0x1. You also
> >
> > need to make sure that registers A10-A15 and B10-B15.
> >
> > _____
> >
> > From: c... [mailto:
> c... ] On Behalf Of Michael
> > Anburaj
> > Sent: Friday, December 22, 2006 11:35 AM
> > To: c...
> > Subject: [c6x] Issue with DSP_fft16x16t - DSPLIB func & GIE
> >
> >
> >
> > Hi,
> >
> > I finally got the 'DSP_fft16x16t' DSPLIB function
> > working on the 6455, without much struggle. But,
> > Initially I stumbled across an issue; 'DSP_fft16x16t'
> > disables the GIE in CSR. I added code to turn it back
> > on after the control returns from 'DSP_fft16x16t'.
> >
> > Questions:
> > 1. Is this the expected behavior? I have read some
> > threads mentioning this. I come from ARM/MIPS world,
> > so in my opinion, masking the interrupt while
> > computing the FFT is fine, but it should restore it
> > back to what it was before entering the routine. In
> > multi-instruction fetch DSP architecture different set
> > of rules may apply, so please let me know.
> > a. Should the routine restore back GIE or leave it
> > disabled?
> > b. If it should restore GIE, then in that case is
> > something wrong with my image?
> >
> > Also, 1 more thing - for some reason this fft routine
> > does not work well with fft sizes less than 64. I am
> > sure, I have followed all the alignment & input
> > scaling requirements, but still the output does not
> > make any sense,. I may be wrong.
> >
> > Cheers,
> > -Mike.
>

--
World Belongs to few enthusiasts who keeps kool

Michael-

I would add to Sankaran's helpful comments below: the routine should *restore* GIE. That is, whatever state GIE is
in when entering the routine, make things the same when leaving.

If GIE is off for good reason when entering your routine and then on when it shouldn't be when leaving, that's another
type of bug you would have to fight.

-Jeff
> a. Should the routine restore back GIE or leave it
> disabled?
>
> The routine should restore the GIE once it has finished the multiple
> register assignment code during the
>
> Software pipelined code phase, so the user should not have to do anything,
> the routine manages GIE
>
> on its own.
>
> b. There may be a bug with the stack management code, which saves and
> restores CSR, whose lowest bit is
>
> GIE. If I were you I would make sure that my CSR is getting restored
> correctly. If the only thing wrong with
>
> it is that GIE is not turned o, once you exit, you can OR CSR with 0x1, as
> follows CSR |= 0x1. You also
>
> need to make sure that registers A10-A15 and B10-B15.
>
> _____
>
> From: c... [mailto:c...] On Behalf Of Michael
> Anburaj
> Sent: Friday, December 22, 2006 11:35 AM
> To: c...
> Subject: [c6x] Issue with DSP_fft16x16t - DSPLIB func & GIE
>
> Hi,
>
> I finally got the 'DSP_fft16x16t' DSPLIB function
> working on the 6455, without much struggle. But,
> Initially I stumbled across an issue; 'DSP_fft16x16t'
> disables the GIE in CSR. I added code to turn it back
> on after the control returns from 'DSP_fft16x16t'.
>
> Questions:
> 1. Is this the expected behavior? I have read some
> threads mentioning this. I come from ARM/MIPS world,
> so in my opinion, masking the interrupt while
> computing the FFT is fine, but it should restore it
> back to what it was before entering the routine. In
> multi-instruction fetch DSP architecture different set
> of rules may apply, so please let me know.
> a. Should the routine restore back GIE or leave it
> disabled?
> b. If it should restore GIE, then in that case is
> something wrong with my image?
>
> Also, 1 more thing - for some reason this fft routine
> does not work well with fft sizes less than 64. I am
> sure, I have followed all the alignment & input
> scaling requirements, but still the output does not
> make any sense,. I may be wrong.
>
> Cheers,
> -Mike.

a. Should the routine restore back GIE or leave it
disabled?

The routine should restore the GIE once it has finished the multiple
register assignment code during the

Software pipelined code phase, so the user should not have to do anything,
the routine manages GIE

on its own.

b. There may be a bug with the stack management code, which saves and
restores CSR, whose lowest bit is

GIE. If I were you I would make sure that my CSR is getting restored
correctly. If the only thing wrong with

it is that GIE is not turned o, once you exit, you can OR CSR with 0x1, as
follows CSR |= 0x1. You also

need to make sure that registers A10-A15 and B10-B15.

_____

From: c... [mailto:c...] On Behalf Of Michael
Anburaj
Sent: Friday, December 22, 2006 11:35 AM
To: c...
Subject: [c6x] Issue with DSP_fft16x16t - DSPLIB func & GIE

Hi,

I finally got the 'DSP_fft16x16t' DSPLIB function
working on the 6455, without much struggle. But,
Initially I stumbled across an issue; 'DSP_fft16x16t'
disables the GIE in CSR. I added code to turn it back
on after the control returns from 'DSP_fft16x16t'.

Questions:
1. Is this the expected behavior? I have read some
threads mentioning this. I come from ARM/MIPS world,
so in my opinion, masking the interrupt while
computing the FFT is fine, but it should restore it
back to what it was before entering the routine. In
multi-instruction fetch DSP architecture different set
of rules may apply, so please let me know.
a. Should the routine restore back GIE or leave it
disabled?
b. If it should restore GIE, then in that case is
something wrong with my image?

Also, 1 more thing - for some reason this fft routine
does not work well with fft sizes less than 64. I am
sure, I have followed all the alignment & input
scaling requirements, but still the output does not
make any sense,. I may be wrong.

Cheers,
-Mike.

Hi,

I finally got the DSP_fft16x16t DSPLIB function
working on the 6455, without much struggle. But,
Initially I stumbled across an issue; DSP_fft16x16t
disables the GIE in CSR. I added code to turn it back
on after the control returns from DSP_fft16x16t.

Questions:
1. Is this the expected behavior? I have read some
threads mentioning this I come from ARM/MIPS world,
so in my opinion, masking the interrupt while
computing the FFT is fine, but it should restore it
back to what it was before entering the routine. In
multi-instruction fetch DSP architecture different set
of rules may apply, so please let me know.
a. Should the routine restore back GIE or leave it
disabled?
b. If it should restore GIE, then in that case is
something wrong with my image?

Also, 1 more thing for some reason this fft routine
does not work well with fft sizes less than 64. I am
sure, I have followed all the alignment & input
scaling requirements, but still the output does not
make any sense, I may be wrong.

Cheers,
-Mike.

__________________________________________________