[6727 uhpi]

I am using the DSP as a peripheral to an FPGA. the timing on the fpga
meets all the requirements for the DSP (from what I can see on a logic
analyzer) so I am only using the read/write, hcntl, and ready lines,
in addition to the 16-bits of data for half-word mode. the byte
enables are tied active, the hds pins are set one high the other low,
the int- is tied high, as is the has line. I also have those made GPIO
pins so that they will see the default anyway.

I have it set for half-word mode and I am not using HAS. I have the
PLL set to 250MHz.

My problem is that I can read and write but not consistently.
sometimes, I get the whole 32-bit word transfered, often only half of
it. The auto-increment does seem to register the correct count but I
only see half of the tranfer in the ram sometimes. It is not consistent.

I am sending the simple set up code I have for test, probably I have
something set wrong?

Or just any thoughts?

#define CHIP_6713
#include
#include
//#include "mcasp1.h"
#include

unsigned int * CfgHpi;
unsigned int * Hpic;
unsigned int * Gpioen;
unsigned int * Hpiaw;
unsigned int * Hpiar;
unsigned int * memory;
unsigned int * pwremu;
unsigned int * memory;
unsigned int * adrmsb;
unsigned int * adrnmsb;
/*----*/

/**********************************************************************/
/* Main */
/**********************************************************************/
void main() {
int i,port;
int error = 0;

init_pll();

CfgHpi = (unsigned int *)0x40000008;
Gpioen = (unsigned int *) 0x4300000c;
Hpic = (unsigned int *)0x43000030;
Hpiaw = (unsigned int *) 0x43000034;
Hpiar = (unsigned int *) 0x43000038;
memory = (unsigned int *) 0x80000000;
pwremu = (unsigned int *) 0x43000004;
adrmsb = (unsigned int *) 0x4000000c;
adrnmsb = (unsigned int *) 0x40000010;
memory = (unsigned int *) 0x80000000;
/* Configuration for DEVCFG register */
*CfgHpi = 0x2;
*adrmsb = 0x80;
*adrnmsb = 0x0;
*CfgHpi = 0x3;
*Hpic = 0x00;
*Gpioen = 0x1e4c;
*pwremu = 0x1;

for(i=0;i<16;i++){
*memory++ = i;
}

while(1);

}

Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467 Start a New Thread

Woshidon,

Just a few inconclusive details.

--I do not see where you are writing anything to the FPGA.
--I do not see where you are reading anything from the FPGA.
perhaps I'm missing some key detail

--The *memory++ = i; statement is full of bad news.
perhaps the following two statements instead
*memory = i; which sets the 32 bit value at 'memory' to the current value of i
memory++; which steps the integer pointer 'memory' forward by 32 bits.

--I do see that the first 16 long words of RAM (int being 32 bits long) are being set to 0...15
--I do see that the data transfers to/from the FPGA are set for 16 bits per access, but the code is
trying to pass 32 bits at a time.

R. Williams

---------- Original Message -----------
From: "woshidon"
To: c...
Sent: Sat, 02 Feb 2008 02:46:25 -0000
Subject: [c6x] [6727 uhpi]

> I am using the DSP as a peripheral to an FPGA. the timing on the fpga
> meets all the requirements for the DSP (from what I can see on a logic
> analyzer) so I am only using the read/write, hcntl, and ready lines,
> in addition to the 16-bits of data for half-word mode. the byte
> enables are tied active, the hds pins are set one high the other low,
> the int- is tied high, as is the has line. I also have those made GPIO
> pins so that they will see the default anyway.
>
> I have it set for half-word mode and I am not using HAS. I have the
> PLL set to 250MHz.
>
> My problem is that I can read and write but not consistently.
> sometimes, I get the whole 32-bit word transfered, often only half of
> it. The auto-increment does seem to register the correct count but I
> only see half of the tranfer in the ram sometimes. It is not consistent.
>
> I am sending the simple set up code I have for test, probably I have
> something set wrong?
>
> Or just any thoughts?
>
> #define CHIP_6713
> #include
> #include
> //#include "mcasp1.h"
> #include unsigned int * CfgHpi;
> unsigned int * Hpic;
> unsigned int * Gpioen;
> unsigned int * Hpiaw;
> unsigned int * Hpiar;
> unsigned int * memory;
> unsigned int * pwremu;
> unsigned int * memory;
> unsigned int * adrmsb;
> unsigned int * adrnmsb;
> /*----*/
>
> /**********************************************************************/
> /* Main */
> /**********************************************************************/
> void main() {
>
> int i,port;
> int error = 0;
>
> init_pll();
>
> CfgHpi = (unsigned int *)0x40000008;
> Gpioen = (unsigned int *) 0x4300000c;
> Hpic = (unsigned int *)0x43000030;
> Hpiaw = (unsigned int *) 0x43000034;
> Hpiar = (unsigned int *) 0x43000038;
> memory = (unsigned int *) 0x80000000;
> pwremu = (unsigned int *) 0x43000004;
> adrmsb = (unsigned int *) 0x4000000c;
> adrnmsb = (unsigned int *) 0x40000010;
> memory = (unsigned int *) 0x80000000;
> /* Configuration for DEVCFG register */
> *CfgHpi = 0x2;
> *adrmsb = 0x80;
> *adrnmsb = 0x0;
> *CfgHpi = 0x3;
> *Hpic = 0x00;
> *Gpioen = 0x1e4c;
> *pwremu = 0x1;
>
> for(i=0;i<16;i++){
> *memory++ = i;
> }
>
> while(1);
>
> }
------- End of Original Message -------

Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467 Start a New Thread

Woshi Don-

It's not clear what you're doing. The HPI peripheral is a slave, so you must be using the FPGA to read/write 6727
memory, right? So you are reading/writing memory at 0x80000000? First, that's not internal memory... second you are
expecting the FPGA to read values 0 to 15?

Is this correct? If so, I suggest a) that you test internal memory first, and b) you use some test values that allow
you to "see" what's going on more clearly, for example values that increment in both low and high 16-bit halves.

Also a couple of questions -- is your FPGA code setting /HCS prior to checking HRDY? What is the FPGA clock and how
many clock cycles a) after /HCS and before checking HRDY, b) after setting HCNTL and H/RW before strobing /HDS? How
sure are you the internal clock rate is truly 250 MHz? Did you measure any of the CLKOUT signals? If the internal
rate exceeds the spec that can either mess up the DSP internal circuitry (HPI results undefined) or exceed your FPGA
timing.

-Jeff

> I am using the DSP as a peripheral to an FPGA. the timing on the fpga
> meets all the requirements for the DSP (from what I can see on a logic
> analyzer) so I am only using the read/write, hcntl, and ready lines,
> in addition to the 16-bits of data for half-word mode. the byte
> enables are tied active, the hds pins are set one high the other low,
> the int- is tied high, as is the has line. I also have those made GPIO
> pins so that they will see the default anyway.
>
> I have it set for half-word mode and I am not using HAS. I have the
> PLL set to 250MHz.
>
> My problem is that I can read and write but not consistently.
> sometimes, I get the whole 32-bit word transfered, often only half of
> it. The auto-increment does seem to register the correct count but I
> only see half of the tranfer in the ram sometimes. It is not consistent.
>
> I am sending the simple set up code I have for test, probably I have
> something set wrong?
>
> Or just any thoughts?
>
> #define CHIP_6713
> #include
> #include
> //#include "mcasp1.h"
> #include unsigned int * CfgHpi;
> unsigned int * Hpic;
> unsigned int * Gpioen;
> unsigned int * Hpiaw;
> unsigned int * Hpiar;
> unsigned int * memory;
> unsigned int * pwremu;
> unsigned int * memory;
> unsigned int * adrmsb;
> unsigned int * adrnmsb;
> /*----*/
>
> /**********************************************************************/
> /* Main */
> /**********************************************************************/
> void main() {
> int i,port;
> int error = 0;
>
> init_pll();
>
> CfgHpi = (unsigned int *)0x40000008;
> Gpioen = (unsigned int *) 0x4300000c;
> Hpic = (unsigned int *)0x43000030;
> Hpiaw = (unsigned int *) 0x43000034;
> Hpiar = (unsigned int *) 0x43000038;
> memory = (unsigned int *) 0x80000000;
> pwremu = (unsigned int *) 0x43000004;
> adrmsb = (unsigned int *) 0x4000000c;
> adrnmsb = (unsigned int *) 0x40000010;
> memory = (unsigned int *) 0x80000000;
> /* Configuration for DEVCFG register */
> *CfgHpi = 0x2;
> *adrmsb = 0x80;
> *adrnmsb = 0x0;
> *CfgHpi = 0x3;
> *Hpic = 0x00;
> *Gpioen = 0x1e4c;
> *pwremu = 0x1;
>
> for(i=0;i<16;i++){
> *memory++ = i;
> }
>
> while(1);
>
> }

Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467 Start a New Thread

This was provided only as information. It is the initialization code
to set up the UHPI for transfers from the DSP.
The memory space indicated by the pointer is where the data is
supposed to go, I put this in just to see that it could be written to.
(Though it is not part of the question I am curious what the bad news
is associated with writing the index to memory and incrementing the
pointer, which is what I meant and what I understood I was doing.)

Perhaps you are onto the problem, because I have poured over the data
sheets many times, and it is my understanding that setting the
interface to half word did not disable 32 bit transfers but expected
two consecutive transfers of 16 bits arbitrated by the HHWIL bit. Is
this wrong? I know it is something stupid and I don't always get it
the first time.

I have a cpu in the FPGA writing 32-bits to the DSP in 16-bit chunks
with the HHWIL bit working as described in the data sheet. In fact all
the timing as as per the diagrams for NO-HAS half-word transfers- at
least as testified to by a logic analyzer.
Don
On 2008, Feb, 2, at 5:57 PM, Richard Williams wrote:

> Woshidon,
>
> Just a few inconclusive details.
>
> --I do not see where you are writing anything to the FPGA.
> --I do not see where you are reading anything from the FPGA.
> perhaps I'm missing some key detail
>
> --The *memory++ = i; statement is full of bad news.
> perhaps the following two statements instead
> *memory = i; which sets the 32 bit value at 'memory' to the current
> value of i
> memory++; which steps the integer pointer 'memory' forward by 32
> bits.
>
> --I do see that the first 16 long words of RAM (int being 32 bits
> long) are being set to 0...15
> --I do see that the data transfers to/from the FPGA are set for 16
> bits per access, but the code is
> trying to pass 32 bits at a time.
>
> R. Williams
>
> ---------- Original Message -----------
> From: "woshidon"
> To: c...
> Sent: Sat, 02 Feb 2008 02:46:25 -0000
> Subject: [c6x] [6727 uhpi]
>
>> I am using the DSP as a peripheral to an FPGA. the timing on the fpga
>> meets all the requirements for the DSP (from what I can see on a
>> logic
>> analyzer) so I am only using the read/write, hcntl, and ready lines,
>> in addition to the 16-bits of data for half-word mode. the byte
>> enables are tied active, the hds pins are set one high the other low,
>> the int- is tied high, as is the has line. I also have those made
>> GPIO
>> pins so that they will see the default anyway.
>>
>> I have it set for half-word mode and I am not using HAS. I have the
>> PLL set to 250MHz.
>>
>> My problem is that I can read and write but not consistently.
>> sometimes, I get the whole 32-bit word transfered, often only half of
>> it. The auto-increment does seem to register the correct count but I
>> only see half of the tranfer in the ram sometimes. It is not
>> consistent.
>>
>> I am sending the simple set up code I have for test, probably I have
>> something set wrong?
>>
>> Or just any thoughts?
>>
>> #define CHIP_6713
>> #include
>> #include
>> //#include "mcasp1.h"
>> #include
>>
>> unsigned int * CfgHpi;
>> unsigned int * Hpic;
>> unsigned int * Gpioen;
>> unsigned int * Hpiaw;
>> unsigned int * Hpiar;
>> unsigned int * memory;
>> unsigned int * pwremu;
>> unsigned int * memory;
>> unsigned int * adrmsb;
>> unsigned int * adrnmsb;
>> /
>> *----*/
>>
>> /
>> **********************************************************************/
>> /*
>> Main */
>> /
>> **********************************************************************/
>> void main() {
>>
>> int i,port;
>> int error = 0;
>>
>> init_pll();
>>
>> CfgHpi = (unsigned int *)0x40000008;
>> Gpioen = (unsigned int *) 0x4300000c;
>> Hpic = (unsigned int *)0x43000030;
>> Hpiaw = (unsigned int *) 0x43000034;
>> Hpiar = (unsigned int *) 0x43000038;
>> memory = (unsigned int *) 0x80000000;
>> pwremu = (unsigned int *) 0x43000004;
>> adrmsb = (unsigned int *) 0x4000000c;
>> adrnmsb = (unsigned int *) 0x40000010;
>> memory = (unsigned int *) 0x80000000;
>> /* Configuration for DEVCFG register */
>> *CfgHpi = 0x2;
>> *adrmsb = 0x80;
>> *adrnmsb = 0x0;
>> *CfgHpi = 0x3;
>> *Hpic = 0x00;
>> *Gpioen = 0x1e4c;
>> *pwremu = 0x1;
>>
>> for(i=0;i<16;i++){
>> *memory++ = i;
>> }
>>
>> while(1);
>>
>> }
> ------- End of Original Message -------
>

Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467 Start a New Thread

I am sorry. I sent the whole program because I wanted to make sure I
didn't edit something out that was actually the problem and mislead
people. Instead, I gave you too much extraneous stuff. That short bit
of code to write external memory was just put there to prove I could
and to set up the values before the FPGA wrote to those same
locations. FPGA writes occur but sometimes I am missing the high half
of the word and sometimes the low half with the pieces of the words
that make it concatenated to form new 'words' in this area. The HPI
write pointers appear to increment correctly, however (very confusing
for me) but I can see that either it didn't see the HHWIL and or
didn't actually post-increment.

Please ignore the write to external RAM.

Yes, I am writing to external RAM with the FPGA, but the same problem
exists if I write to 0x10000000, internal ram.

I can see the Hrdy working correctly relative to HCS-. All four
conditions described in the data sheet and the application notes on
UHPI have been tested and work as expected with the HRDY either
accepting the data (staying low) or stalling the FPGA (going high)
just as described.

Because the timing (according to the logic analyzer) met all the
conditions in the data sheet, I do not use HAS- or HDS1 or HDS2, HAS-
is permanently high with HDS1 high and HDS2 low. The read/write strobe
occurs well before HCS-. But I will make some more tests.

I have not proven that the PLL is truly set to 250MHz with a scope-
this is a very good question. I did walk through the setup to see the
multipliers were correct and the clocks were also correctly sync'd -
that is with the special sync registers. I will try to check that
today. Thanks.

I will get back to you as soon as I can get some data.

Don

On 2008, Feb, 2, at 9:45 PM, Jeff Brower wrote:

> Woshi Don-
>
> It's not clear what you're doing. The HPI peripheral is a slave, so
> you must be using the FPGA to read/write 6727
> memory, right? So you are reading/writing memory at 0x80000000?
> First, that's not internal memory... second you are
> expecting the FPGA to read values 0 to 15?
>
> Is this correct? If so, I suggest a) that you test internal memory
> first, and b) you use some test values that allow
> you to "see" what's going on more clearly, for example values that
> increment in both low and high 16-bit halves.
>
> Also a couple of questions -- is your FPGA code setting /HCS prior
> to checking HRDY? What is the FPGA clock and how
> many clock cycles a) after /HCS and before checking HRDY, b) after
> setting HCNTL and H/RW before strobing /HDS? How
> sure are you the internal clock rate is truly 250 MHz? Did you
> measure any of the CLKOUT signals? If the internal
> rate exceeds the spec that can either mess up the DSP internal
> circuitry (HPI results undefined) or exceed your FPGA
> timing.
>
> -Jeff
>
> > I am using the DSP as a peripheral to an FPGA. the timing on the
> fpga
> > meets all the requirements for the DSP (from what I can see on a
> logic
> > analyzer) so I am only using the read/write, hcntl, and ready lines,
> > in addition to the 16-bits of data for half-word mode. the byte
> > enables are tied active, the hds pins are set one high the other
> low,
> > the int- is tied high, as is the has line. I also have those made
> GPIO
> > pins so that they will see the default anyway.
> >
> > I have it set for half-word mode and I am not using HAS. I have the
> > PLL set to 250MHz.
> >
> > My problem is that I can read and write but not consistently.
> > sometimes, I get the whole 32-bit word transfered, often only half
> of
> > it. The auto-increment does seem to register the correct count but I
> > only see half of the tranfer in the ram sometimes. It is not
> consistent.
> >
> > I am sending the simple set up code I have for test, probably I have
> > something set wrong?
> >
> > Or just any thoughts?
> >
> > #define CHIP_6713
> > #include
> > #include
> > //#include "mcasp1.h"
> > #include
> >
> > unsigned int * CfgHpi;
> > unsigned int * Hpic;
> > unsigned int * Gpioen;
> > unsigned int * Hpiaw;
> > unsigned int * Hpiar;
> > unsigned int * memory;
> > unsigned int * pwremu;
> > unsigned int * memory;
> > unsigned int * adrmsb;
> > unsigned int * adrnmsb;
> > /*----------------------*/
> >
> > /
> **********************************************************************/
> > /* Main */
> > /
> **********************************************************************/
> > void main() {
> >
> >
> > int i,port;
> > int error = 0;
> >
> > init_pll();
> >
> > CfgHpi = (unsigned int *)0x40000008;
> > Gpioen = (unsigned int *) 0x4300000c;
> > Hpic = (unsigned int *)0x43000030;
> > Hpiaw = (unsigned int *) 0x43000034;
> > Hpiar = (unsigned int *) 0x43000038;
> > memory = (unsigned int *) 0x80000000;
> > pwremu = (unsigned int *) 0x43000004;
> > adrmsb = (unsigned int *) 0x4000000c;
> > adrnmsb = (unsigned int *) 0x40000010;
> > memory = (unsigned int *) 0x80000000;
> > /* Configuration for DEVCFG register */
> > *CfgHpi = 0x2;
> > *adrmsb = 0x80;
> > *adrnmsb = 0x0;
> > *CfgHpi = 0x3;
> > *Hpic = 0x00;
> > *Gpioen = 0x1e4c;
> > *pwremu = 0x1;
> >
> > for(i=0;i<16;i++){
> > *memory++ = i;
> > }
> >
> > while(1);
> >
> > }
> Start a New Thread

Maybe I am. I thought that all I needed to do to write to the internal
registers/memory was toggle the appropriate external hand shake signals!
I set HPIC, write to HPIAW and start to write values into what I
expect to be memory at 0x80000000.
What else do I have to do?

But you point something out that I must be missing somehow. (You say
and someone else did too.) That I am set for 16-bits per access but
writing 32.
You are right, but I thought I could do this.

My processor in the FPGA is 32-bits. When it writes, it writes the low
half-word first then after setting HHWIL it writes the high half-word.
As far as I understood the examples and descriptions, that was correct.

Are you saying I can't do this? What do I have to do to get 32-bits in
and out of the DSP through the half-word interface?

Thanks,
Don

On 2008, Feb, 2, at 5:57 PM, Richard Williams wrote:

> Woshidon,
>
> Just a few inconclusive details.
>
> --I do not see where you are writing anything to the FPGA.
> --I do not see where you are reading anything from the FPGA.
> perhaps I'm missing some key detail
>
> --The *memory++ = i; statement is full of bad news.
> perhaps the following two statements instead
> *memory = i; which sets the 32 bit value at 'memory' to the current
> value of i
> memory++; which steps the integer pointer 'memory' forward by 32 bits.
>
> --I do see that the first 16 long words of RAM (int being 32 bits
> long) are being set to 0...15
> --I do see that the data transfers to/from the FPGA are set for 16
> bits per access, but the code is
> trying to pass 32 bits at a time.
>
> R. Williams
>
> ---------- Original Message -----------
> From: "woshidon"
> To: c...
> Sent: Sat, 02 Feb 2008 02:46:25 -0000
> Subject: [c6x] [6727 uhpi]
>
> > I am using the DSP as a peripheral to an FPGA. the timing on the
> fpga
> > meets all the requirements for the DSP (from what I can see on a
> logic
> > analyzer) so I am only using the read/write, hcntl, and ready lines,
> > in addition to the 16-bits of data for half-word mode. the byte
> > enables are tied active, the hds pins are set one high the other
> low,
> > the int- is tied high, as is the has line. I also have those made
> GPIO
> > pins so that they will see the default anyway.
> >
> > I have it set for half-word mode and I am not using HAS. I have the
> > PLL set to 250MHz.
> >
> > My problem is that I can read and write but not consistently.
> > sometimes, I get the whole 32-bit word transfered, often only half
> of
> > it. The auto-increment does seem to register the correct count but I
> > only see half of the tranfer in the ram sometimes. It is not
> consistent.
> >
> > I am sending the simple set up code I have for test, probably I have
> > something set wrong?
> >
> > Or just any thoughts?
> >
> > #define CHIP_6713
> > #include
> > #include
> > //#include "mcasp1.h"
> > #include
> >
> > unsigned int * CfgHpi;
> > unsigned int * Hpic;
> > unsigned int * Gpioen;
> > unsigned int * Hpiaw;
> > unsigned int * Hpiar;
> > unsigned int * memory;
> > unsigned int * pwremu;
> > unsigned int * memory;
> > unsigned int * adrmsb;
> > unsigned int * adrnmsb;
> > /*----------------------*/
> >
> > /
> **********************************************************************/
> > /* Main */
> > /
> **********************************************************************/
> > void main() {
> >
> > int i,port;
> > int error = 0;
> >
> > init_pll();
> >
> > CfgHpi = (unsigned int *)0x40000008;
> > Gpioen = (unsigned int *) 0x4300000c;
> > Hpic = (unsigned int *)0x43000030;
> > Hpiaw = (unsigned int *) 0x43000034;
> > Hpiar = (unsigned int *) 0x43000038;
> > memory = (unsigned int *) 0x80000000;
> > pwremu = (unsigned int *) 0x43000004;
> > adrmsb = (unsigned int *) 0x4000000c;
> > adrnmsb = (unsigned int *) 0x40000010;
> > memory = (unsigned int *) 0x80000000;
> > /* Configuration for DEVCFG register */
> > *CfgHpi = 0x2;
> > *adrmsb = 0x80;
> > *adrnmsb = 0x0;
> > *CfgHpi = 0x3;
> > *Hpic = 0x00;
> > *Gpioen = 0x1e4c;
> > *pwremu = 0x1;
> >
> > for(i=0;i<16;i++){
> > *memory++ = i;
> > }
> >
> > while(1);
> >
> > }
> ------- End of Original Message -------
> Start a New Thread

Don-

> I am sorry. I sent the whole program because I wanted to make sure I
> didn't edit something out that was actually the problem and mislead
> people. Instead, I gave you too much extraneous stuff. That short bit
> of code to write external memory was just put there to prove I could
> and to set up the values before the FPGA wrote to those same
> locations. FPGA writes occur but sometimes I am missing the high half
> of the word and sometimes the low half with the pieces of the words
> that make it concatenated to form new 'words' in this area. The HPI
> write pointers appear to increment correctly, however (very confusing
> for me) but I can see that either it didn't see the HHWIL and or
> didn't actually post-increment.
>
> Please ignore the write to external RAM.
>
> Yes, I am writing to external RAM with the FPGA, but the same problem
> exists if I write to 0x10000000, internal ram.
>
> I can see the Hrdy working correctly relative to HCS-. All four
> conditions described in the data sheet and the application notes on
> UHPI have been tested and work as expected with the HRDY either
> accepting the data (staying low) or stalling the FPGA (going high)
> just as described.
>
> Because the timing (according to the logic analyzer) met all the
> conditions in the data sheet, I do not use HAS- or HDS1 or HDS2, HAS-
> is permanently high with HDS1 high and HDS2 low. The read/write strobe
> occurs well before HCS-. But I will make some more tests.
>
> I have not proven that the PLL is truly set to 250MHz with a scope-
> this is a very good question. I did walk through the setup to see the
> multipliers were correct and the clocks were also correctly sync'd -
> that is with the special sync registers. I will try to check that
> today. Thanks.
>
> I will get back to you as soon as I can get some data.

How can you get away without using data strobe (either HDS1 or HDS2)? I don't think the data sheet permits you to do
this -- HR/W should be asserted and stable (meeting minimum setup time) *prior* to internal HDS, and all timing should
be relative to internal HDS active.

Also, I would suggest you test HPI read first, then you cut the problem in half. Your DSP test code can initialize
some internal mem data, then FPGA reads it. Make sure you can do all combinations of read (various addresses,
autoincrement, non-autoincrement, etc) then test HPI writes.

I don't know details of C672x as I do C671x, but I would have thought that internal mem starts at zero rather than
0x10000000. I'm sure you've checked this, but I am curious though, what memory is at location 0x0? The older C620x
devices split internal data and program mem, and program mem started at 0x0, so maybe something like that is going on.

-Jeff

> On 2008, Feb, 2, at 9:45 PM, Jeff Brower wrote:
>
>> Woshi Don-
>>
>> It's not clear what you're doing. The HPI peripheral is a slave, so
>> you must be using the FPGA to read/write 6727
>> memory, right? So you are reading/writing memory at 0x80000000?
>> First, that's not internal memory... second you are
>> expecting the FPGA to read values 0 to 15?
>>
>> Is this correct? If so, I suggest a) that you test internal memory
>> first, and b) you use some test values that allow
>> you to "see" what's going on more clearly, for example values that
>> increment in both low and high 16-bit halves.
>>
>> Also a couple of questions -- is your FPGA code setting /HCS prior
>> to checking HRDY? What is the FPGA clock and how
>> many clock cycles a) after /HCS and before checking HRDY, b) after
>> setting HCNTL and H/RW before strobing /HDS? How
>> sure are you the internal clock rate is truly 250 MHz? Did you
>> measure any of the CLKOUT signals? If the internal
>> rate exceeds the spec that can either mess up the DSP internal
>> circuitry (HPI results undefined) or exceed your FPGA
>> timing.
>>
>> -Jeff
>>
>> > I am using the DSP as a peripheral to an FPGA. the timing on the
>> fpga
>> > meets all the requirements for the DSP (from what I can see on a
>> logic
>> > analyzer) so I am only using the read/write, hcntl, and ready lines,
>> > in addition to the 16-bits of data for half-word mode. the byte
>> > enables are tied active, the hds pins are set one high the other
>> low,
>> > the int- is tied high, as is the has line. I also have those made
>> GPIO
>> > pins so that they will see the default anyway.
>> >
>> > I have it set for half-word mode and I am not using HAS. I have the
>> > PLL set to 250MHz.
>> >
>> > My problem is that I can read and write but not consistently.
>> > sometimes, I get the whole 32-bit word transfered, often only half
>> of
>> > it. The auto-increment does seem to register the correct count but I
>> > only see half of the tranfer in the ram sometimes. It is not
>> consistent.
>> >
>> > I am sending the simple set up code I have for test, probably I have
>> > something set wrong?
>> >
>> > Or just any thoughts?
>> >
>> > #define CHIP_6713
>> > #include
>> > #include
>> > //#include "mcasp1.h"
>> > #include
>> >
>> > unsigned int * CfgHpi;
>> > unsigned int * Hpic;
>> > unsigned int * Gpioen;
>> > unsigned int * Hpiaw;
>> > unsigned int * Hpiar;
>> > unsigned int * memory;
>> > unsigned int * pwremu;
>> > unsigned int * memory;
>> > unsigned int * adrmsb;
>> > unsigned int * adrnmsb;
>> > /*----------------------*/
>> >
>> > /
>> **********************************************************************/
>> > /* Main */
>> > /
>> **********************************************************************/
>> > void main() {
>> >
>> >
>> > int i,port;
>> > int error = 0;
>> >
>> > init_pll();
>> >
>> > CfgHpi = (unsigned int *)0x40000008;
>> > Gpioen = (unsigned int *) 0x4300000c;
>> > Hpic = (unsigned int *)0x43000030;
>> > Hpiaw = (unsigned int *) 0x43000034;
>> > Hpiar = (unsigned int *) 0x43000038;
>> > memory = (unsigned int *) 0x80000000;
>> > pwremu = (unsigned int *) 0x43000004;
>> > adrmsb = (unsigned int *) 0x4000000c;
>> > adrnmsb = (unsigned int *) 0x40000010;
>> > memory = (unsigned int *) 0x80000000;
>> > /* Configuration for DEVCFG register */
>> > *CfgHpi = 0x2;
>> > *adrmsb = 0x80;
>> > *adrnmsb = 0x0;
>> > *CfgHpi = 0x3;
>> > *Hpic = 0x00;
>> > *Gpioen = 0x1e4c;
>> > *pwremu = 0x1;
>> >
>> > for(i=0;i<16;i++){
>> > *memory++ = i;
>> > }
>> >
>> > while(1);

Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467 Start a New Thread

As I understood it, i could as long as HCS- went true after the read/
write, hcntl and address and data lines were set. I will check again.
Oops, maybe I have the internal memory address wrong? I will check
that too.
Thanks for all your help.
Don

On 2008, Feb, 4, at 8:03 AM, Jeff Brower wrote:

> Don-
>
>> I am sorry. I sent the whole program because I wanted to make sure I
>> didn't edit something out that was actually the problem and mislead
>> people. Instead, I gave you too much extraneous stuff. That short bit
>> of code to write external memory was just put there to prove I could
>> and to set up the values before the FPGA wrote to those same
>> locations. FPGA writes occur but sometimes I am missing the high half
>> of the word and sometimes the low half with the pieces of the words
>> that make it concatenated to form new 'words' in this area. The HPI
>> write pointers appear to increment correctly, however (very confusing
>> for me) but I can see that either it didn't see the HHWIL and or
>> didn't actually post-increment.
>>
>> Please ignore the write to external RAM.
>>
>> Yes, I am writing to external RAM with the FPGA, but the same problem
>> exists if I write to 0x10000000, internal ram.
>>
>> I can see the Hrdy working correctly relative to HCS-. All four
>> conditions described in the data sheet and the application notes on
>> UHPI have been tested and work as expected with the HRDY either
>> accepting the data (staying low) or stalling the FPGA (going high)
>> just as described.
>>
>> Because the timing (according to the logic analyzer) met all the
>> conditions in the data sheet, I do not use HAS- or HDS1 or HDS2, HAS-
>> is permanently high with HDS1 high and HDS2 low. The read/write
>> strobe
>> occurs well before HCS-. But I will make some more tests.
>>
>> I have not proven that the PLL is truly set to 250MHz with a scope-
>> this is a very good question. I did walk through the setup to see the
>> multipliers were correct and the clocks were also correctly sync'd -
>> that is with the special sync registers. I will try to check that
>> today. Thanks.
>>
>> I will get back to you as soon as I can get some data.
>
> How can you get away without using data strobe (either HDS1 or
> HDS2)? I don't think the data sheet permits you to do
> this -- HR/W should be asserted and stable (meeting minimum setup
> time) *prior* to internal HDS, and all timing should
> be relative to internal HDS active.
>
> Also, I would suggest you test HPI read first, then you cut the
> problem in half. Your DSP test code can initialize
> some internal mem data, then FPGA reads it. Make sure you can do
> all combinations of read (various addresses,
> autoincrement, non-autoincrement, etc) then test HPI writes.
>
> I don't know details of C672x as I do C671x, but I would have
> thought that internal mem starts at zero rather than
> 0x10000000. I'm sure you've checked this, but I am curious though,
> what memory is at location 0x0? The older C620x
> devices split internal data and program mem, and program mem started
> at 0x0, so maybe something like that is going on.
>
> -Jeff
>
>> On 2008, Feb, 2, at 9:45 PM, Jeff Brower wrote:
>>
>>> Woshi Don-
>>>
>>> It's not clear what you're doing. The HPI peripheral is a slave, so
>>> you must be using the FPGA to read/write 6727
>>> memory, right? So you are reading/writing memory at 0x80000000?
>>> First, that's not internal memory... second you are
>>> expecting the FPGA to read values 0 to 15?
>>>
>>> Is this correct? If so, I suggest a) that you test internal memory
>>> first, and b) you use some test values that allow
>>> you to "see" what's going on more clearly, for example values that
>>> increment in both low and high 16-bit halves.
>>>
>>> Also a couple of questions -- is your FPGA code setting /HCS prior
>>> to checking HRDY? What is the FPGA clock and how
>>> many clock cycles a) after /HCS and before checking HRDY, b) after
>>> setting HCNTL and H/RW before strobing /HDS? How
>>> sure are you the internal clock rate is truly 250 MHz? Did you
>>> measure any of the CLKOUT signals? If the internal
>>> rate exceeds the spec that can either mess up the DSP internal
>>> circuitry (HPI results undefined) or exceed your FPGA
>>> timing.
>>>
>>> -Jeff
>>>
>>>> I am using the DSP as a peripheral to an FPGA. the timing on the
>>> fpga
>>>> meets all the requirements for the DSP (from what I can see on a
>>> logic
>>>> analyzer) so I am only using the read/write, hcntl, and ready
>>>> lines,
>>>> in addition to the 16-bits of data for half-word mode. the byte
>>>> enables are tied active, the hds pins are set one high the other
>>> low,
>>>> the int- is tied high, as is the has line. I also have those made
>>> GPIO
>>>> pins so that they will see the default anyway.
>>>>
>>>> I have it set for half-word mode and I am not using HAS. I have the
>>>> PLL set to 250MHz.
>>>>
>>>> My problem is that I can read and write but not consistently.
>>>> sometimes, I get the whole 32-bit word transfered, often only half
>>> of
>>>> it. The auto-increment does seem to register the correct count
>>>> but I
>>>> only see half of the tranfer in the ram sometimes. It is not
>>> consistent.
>>>>
>>>> I am sending the simple set up code I have for test, probably I
>>>> have
>>>> something set wrong?
>>>>
>>>> Or just any thoughts?
>>>>
>>>> #define CHIP_6713
>>>> #include
>>>> #include
>>>> //#include "mcasp1.h"
>>>> #include
>>>>
>>>> unsigned int * CfgHpi;
>>>> unsigned int * Hpic;
>>>> unsigned int * Gpioen;
>>>> unsigned int * Hpiaw;
>>>> unsigned int * Hpiar;
>>>> unsigned int * memory;
>>>> unsigned int * pwremu;
>>>> unsigned int * memory;
>>>> unsigned int * adrmsb;
>>>> unsigned int * adrnmsb;
>>>> /*----------------------*/
>>>>
>>>> /
>>> **********************************************************************/
>>>> /* Main */
>>>> /
>>> **********************************************************************/
>>>> void main() {
>>>>
>>>>
>>>> int i,port;
>>>> int error = 0;
>>>>
>>>> init_pll();
>>>>
>>>> CfgHpi = (unsigned int *)0x40000008;
>>>> Gpioen = (unsigned int *) 0x4300000c;
>>>> Hpic = (unsigned int *)0x43000030;
>>>> Hpiaw = (unsigned int *) 0x43000034;
>>>> Hpiar = (unsigned int *) 0x43000038;
>>>> memory = (unsigned int *) 0x80000000;
>>>> pwremu = (unsigned int *) 0x43000004;
>>>> adrmsb = (unsigned int *) 0x4000000c;
>>>> adrnmsb = (unsigned int *) 0x40000010;
>>>> memory = (unsigned int *) 0x80000000;
>>>> /* Configuration for DEVCFG register */
>>>> *CfgHpi = 0x2;
>>>> *adrmsb = 0x80;
>>>> *adrnmsb = 0x0;
>>>> *CfgHpi = 0x3;
>>>> *Hpic = 0x00;
>>>> *Gpioen = 0x1e4c;
>>>> *pwremu = 0x1;
>>>>
>>>> for(i=0;i<16;i++){
>>>> *memory++ = i;
>>>> }
>>>>
>>>> while(1);
>

Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467 Start a New Thread

Don-

> As I understood it, i could as long as HCS- went true after the read/
> write, hcntl and address and data lines were set. I will check again.

If you did that, you'd be violating HRDY timing. You must verify HRDY *before* asserting HDS. That means /HCS needs
to be set as a first step, in order to enable HPI and HRDY output. Depending on the application and power consumption
limitations, you can leave /HCS asserted always, or at least when you're making a series of HPI accesses.

-Jeff

> Oops, maybe I have the internal memory address wrong? I will check
> that too.
> Thanks for all your help.
> Don
>
> On 2008, Feb, 4, at 8:03 AM, Jeff Brower wrote:
>
>> Don-
>>
>>> I am sorry. I sent the whole program because I wanted to make sure I
>>> didn't edit something out that was actually the problem and mislead
>>> people. Instead, I gave you too much extraneous stuff. That short bit
>>> of code to write external memory was just put there to prove I could
>>> and to set up the values before the FPGA wrote to those same
>>> locations. FPGA writes occur but sometimes I am missing the high half
>>> of the word and sometimes the low half with the pieces of the words
>>> that make it concatenated to form new 'words' in this area. The HPI
>>> write pointers appear to increment correctly, however (very confusing
>>> for me) but I can see that either it didn't see the HHWIL and or
>>> didn't actually post-increment.
>>>
>>> Please ignore the write to external RAM.
>>>
>>> Yes, I am writing to external RAM with the FPGA, but the same problem
>>> exists if I write to 0x10000000, internal ram.
>>>
>>> I can see the Hrdy working correctly relative to HCS-. All four
>>> conditions described in the data sheet and the application notes on
>>> UHPI have been tested and work as expected with the HRDY either
>>> accepting the data (staying low) or stalling the FPGA (going high)
>>> just as described.
>>>
>>> Because the timing (according to the logic analyzer) met all the
>>> conditions in the data sheet, I do not use HAS- or HDS1 or HDS2, HAS-
>>> is permanently high with HDS1 high and HDS2 low. The read/write
>>> strobe
>>> occurs well before HCS-. But I will make some more tests.
>>>
>>> I have not proven that the PLL is truly set to 250MHz with a scope-
>>> this is a very good question. I did walk through the setup to see the
>>> multipliers were correct and the clocks were also correctly sync'd -
>>> that is with the special sync registers. I will try to check that
>>> today. Thanks.
>>>
>>> I will get back to you as soon as I can get some data.
>>
>> How can you get away without using data strobe (either HDS1 or
>> HDS2)? I don't think the data sheet permits you to do
>> this -- HR/W should be asserted and stable (meeting minimum setup
>> time) *prior* to internal HDS, and all timing should
>> be relative to internal HDS active.
>>
>> Also, I would suggest you test HPI read first, then you cut the
>> problem in half. Your DSP test code can initialize
>> some internal mem data, then FPGA reads it. Make sure you can do
>> all combinations of read (various addresses,
>> autoincrement, non-autoincrement, etc) then test HPI writes.
>>
>> I don't know details of C672x as I do C671x, but I would have
>> thought that internal mem starts at zero rather than
>> 0x10000000. I'm sure you've checked this, but I am curious though,
>> what memory is at location 0x0? The older C620x
>> devices split internal data and program mem, and program mem started
>> at 0x0, so maybe something like that is going on.
>>
>> -Jeff
>>
>>> On 2008, Feb, 2, at 9:45 PM, Jeff Brower wrote:
>>>
>>>> Woshi Don-
>>>>
>>>> It's not clear what you're doing. The HPI peripheral is a slave, so
>>>> you must be using the FPGA to read/write 6727
>>>> memory, right? So you are reading/writing memory at 0x80000000?
>>>> First, that's not internal memory... second you are
>>>> expecting the FPGA to read values 0 to 15?
>>>>
>>>> Is this correct? If so, I suggest a) that you test internal memory
>>>> first, and b) you use some test values that allow
>>>> you to "see" what's going on more clearly, for example values that
>>>> increment in both low and high 16-bit halves.
>>>>
>>>> Also a couple of questions -- is your FPGA code setting /HCS prior
>>>> to checking HRDY? What is the FPGA clock and how
>>>> many clock cycles a) after /HCS and before checking HRDY, b) after
>>>> setting HCNTL and H/RW before strobing /HDS? How
>>>> sure are you the internal clock rate is truly 250 MHz? Did you
>>>> measure any of the CLKOUT signals? If the internal
>>>> rate exceeds the spec that can either mess up the DSP internal
>>>> circuitry (HPI results undefined) or exceed your FPGA
>>>> timing.
>>>>
>>>> -Jeff
>>>>
>>>>> I am using the DSP as a peripheral to an FPGA. the timing on the
>>>> fpga
>>>>> meets all the requirements for the DSP (from what I can see on a
>>>> logic
>>>>> analyzer) so I am only using the read/write, hcntl, and ready
>>>>> lines,
>>>>> in addition to the 16-bits of data for half-word mode. the byte
>>>>> enables are tied active, the hds pins are set one high the other
>>>> low,
>>>>> the int- is tied high, as is the has line. I also have those made
>>>> GPIO
>>>>> pins so that they will see the default anyway.
>>>>>
>>>>> I have it set for half-word mode and I am not using HAS. I have the
>>>>> PLL set to 250MHz.
>>>>>
>>>>> My problem is that I can read and write but not consistently.
>>>>> sometimes, I get the whole 32-bit word transfered, often only half
>>>> of
>>>>> it. The auto-increment does seem to register the correct count
>>>>> but I
>>>>> only see half of the tranfer in the ram sometimes. It is not
>>>> consistent.
>>>>>
>>>>> I am sending the simple set up code I have for test, probably I
>>>>> have
>>>>> something set wrong?
>>>>>
>>>>> Or just any thoughts?
>>>>>
>>>>> #define CHIP_6713
>>>>> #include
>>>>> #include
>>>>> //#include "mcasp1.h"
>>>>> #include
>>>>>
>>>>> unsigned int * CfgHpi;
>>>>> unsigned int * Hpic;
>>>>> unsigned int * Gpioen;
>>>>> unsigned int * Hpiaw;
>>>>> unsigned int * Hpiar;
>>>>> unsigned int * memory;
>>>>> unsigned int * pwremu;
>>>>> unsigned int * memory;
>>>>> unsigned int * adrmsb;
>>>>> unsigned int * adrnmsb;
>>>>> /*----------------------*/
>>>>>
>>>>> /
>>>> **********************************************************************/
>>>>> /* Main */
>>>>> /
>>>> **********************************************************************/
>>>>> void main() {
>>>>>
>>>>>
>>>>> int i,port;
>>>>> int error = 0;
>>>>>
>>>>> init_pll();
>>>>>
>>>>> CfgHpi = (unsigned int *)0x40000008;
>>>>> Gpioen = (unsigned int *) 0x4300000c;
>>>>> Hpic = (unsigned int *)0x43000030;
>>>>> Hpiaw = (unsigned int *) 0x43000034;
>>>>> Hpiar = (unsigned int *) 0x43000038;
>>>>> memory = (unsigned int *) 0x80000000;
>>>>> pwremu = (unsigned int *) 0x43000004;
>>>>> adrmsb = (unsigned int *) 0x4000000c;
>>>>> adrnmsb = (unsigned int *) 0x40000010;
>>>>> memory = (unsigned int *) 0x80000000;
>>>>> /* Configuration for DEVCFG register */
>>>>> *CfgHpi = 0x2;
>>>>> *adrmsb = 0x80;
>>>>> *adrnmsb = 0x0;
>>>>> *CfgHpi = 0x3;
>>>>> *Hpic = 0x00;
>>>>> *Gpioen = 0x1e4c;
>>>>> *pwremu = 0x1;
>>>>>
>>>>> for(i=0;i<16;i++){
>>>>> *memory++ = i;
>>>>> }
>>>>>
>>>>> while(1);
>>

Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467 Start a New Thread

I was going by note G at the bottom of p.56 of the datasheet: Only
required if needed for strobe timing. Not required if CS- meets strobe
timing requirements. The UHPI_HDS[2]- and HUPI_HDS[1]- opposite. I
have them tied opposite.

Arghh.

On 2008, Feb, 4, at 8:03 AM, Jeff Brower wrote:

> Don-
>
>> I am sorry. I sent the whole program because I wanted to make sure I
>> didn't edit something out that was actually the problem and mislead
>> people. Instead, I gave you too much extraneous stuff. That short bit
>> of code to write external memory was just put there to prove I could
>> and to set up the values before the FPGA wrote to those same
>> locations. FPGA writes occur but sometimes I am missing the high half
>> of the word and sometimes the low half with the pieces of the words
>> that make it concatenated to form new 'words' in this area. The HPI
>> write pointers appear to increment correctly, however (very confusing
>> for me) but I can see that either it didn't see the HHWIL and or
>> didn't actually post-increment.
>>
>> Please ignore the write to external RAM.
>>
>> Yes, I am writing to external RAM with the FPGA, but the same problem
>> exists if I write to 0x10000000, internal ram.
>>
>> I can see the Hrdy working correctly relative to HCS-. All four
>> conditions described in the data sheet and the application notes on
>> UHPI have been tested and work as expected with the HRDY either
>> accepting the data (staying low) or stalling the FPGA (going high)
>> just as described.
>>
>> Because the timing (according to the logic analyzer) met all the
>> conditions in the data sheet, I do not use HAS- or HDS1 or HDS2, HAS-
>> is permanently high with HDS1 high and HDS2 low. The read/write
>> strobe
>> occurs well before HCS-. But I will make some more tests.
>>
>> I have not proven that the PLL is truly set to 250MHz with a scope-
>> this is a very good question. I did walk through the setup to see the
>> multipliers were correct and the clocks were also correctly sync'd -
>> that is with the special sync registers. I will try to check that
>> today. Thanks.
>>
>> I will get back to you as soon as I can get some data.
>
> How can you get away without using data strobe (either HDS1 or
> HDS2)? I don't think the data sheet permits you to do
> this -- HR/W should be asserted and stable (meeting minimum setup
> time) *prior* to internal HDS, and all timing should
> be relative to internal HDS active.
>
> Also, I would suggest you test HPI read first, then you cut the
> problem in half. Your DSP test code can initialize
> some internal mem data, then FPGA reads it. Make sure you can do
> all combinations of read (various addresses,
> autoincrement, non-autoincrement, etc) then test HPI writes.
>
> I don't know details of C672x as I do C671x, but I would have
> thought that internal mem starts at zero rather than
> 0x10000000. I'm sure you've checked this, but I am curious though,
> what memory is at location 0x0? The older C620x
> devices split internal data and program mem, and program mem started
> at 0x0, so maybe something like that is going on.
>
> -Jeff
>
>> On 2008, Feb, 2, at 9:45 PM, Jeff Brower wrote:
>>
>>> Woshi Don-
>>>
>>> It's not clear what you're doing. The HPI peripheral is a slave, so
>>> you must be using the FPGA to read/write 6727
>>> memory, right? So you are reading/writing memory at 0x80000000?
>>> First, that's not internal memory... second you are
>>> expecting the FPGA to read values 0 to 15?
>>>
>>> Is this correct? If so, I suggest a) that you test internal memory
>>> first, and b) you use some test values that allow
>>> you to "see" what's going on more clearly, for example values that
>>> increment in both low and high 16-bit halves.
>>>
>>> Also a couple of questions -- is your FPGA code setting /HCS prior
>>> to checking HRDY? What is the FPGA clock and how
>>> many clock cycles a) after /HCS and before checking HRDY, b) after
>>> setting HCNTL and H/RW before strobing /HDS? How
>>> sure are you the internal clock rate is truly 250 MHz? Did you
>>> measure any of the CLKOUT signals? If the internal
>>> rate exceeds the spec that can either mess up the DSP internal
>>> circuitry (HPI results undefined) or exceed your FPGA
>>> timing.
>>>
>>> -Jeff
>>>
>>>> I am using the DSP as a peripheral to an FPGA. the timing on the
>>> fpga
>>>> meets all the requirements for the DSP (from what I can see on a
>>> logic
>>>> analyzer) so I am only using the read/write, hcntl, and ready
>>>> lines,
>>>> in addition to the 16-bits of data for half-word mode. the byte
>>>> enables are tied active, the hds pins are set one high the other
>>> low,
>>>> the int- is tied high, as is the has line. I also have those made
>>> GPIO
>>>> pins so that they will see the default anyway.
>>>>
>>>> I have it set for half-word mode and I am not using HAS. I have the
>>>> PLL set to 250MHz.
>>>>
>>>> My problem is that I can read and write but not consistently.
>>>> sometimes, I get the whole 32-bit word transfered, often only half
>>> of
>>>> it. The auto-increment does seem to register the correct count
>>>> but I
>>>> only see half of the tranfer in the ram sometimes. It is not
>>> consistent.
>>>>
>>>> I am sending the simple set up code I have for test, probably I
>>>> have
>>>> something set wrong?
>>>>
>>>> Or just any thoughts?
>>>>
>>>> #define CHIP_6713
>>>> #include
>>>> #include
>>>> //#include "mcasp1.h"
>>>> #include
>>>>
>>>> unsigned int * CfgHpi;
>>>> unsigned int * Hpic;
>>>> unsigned int * Gpioen;
>>>> unsigned int * Hpiaw;
>>>> unsigned int * Hpiar;
>>>> unsigned int * memory;
>>>> unsigned int * pwremu;
>>>> unsigned int * memory;
>>>> unsigned int * adrmsb;
>>>> unsigned int * adrnmsb;
>>>> /*----------------------*/
>>>>
>>>> /
>>> **********************************************************************/
>>>> /* Main */
>>>> /
>>> **********************************************************************/
>>>> void main() {
>>>>
>>>>
>>>> int i,port;
>>>> int error = 0;
>>>>
>>>> init_pll();
>>>>
>>>> CfgHpi = (unsigned int *)0x40000008;
>>>> Gpioen = (unsigned int *) 0x4300000c;
>>>> Hpic = (unsigned int *)0x43000030;
>>>> Hpiaw = (unsigned int *) 0x43000034;
>>>> Hpiar = (unsigned int *) 0x43000038;
>>>> memory = (unsigned int *) 0x80000000;
>>>> pwremu = (unsigned int *) 0x43000004;
>>>> adrmsb = (unsigned int *) 0x4000000c;
>>>> adrnmsb = (unsigned int *) 0x40000010;
>>>> memory = (unsigned int *) 0x80000000;
>>>> /* Configuration for DEVCFG register */
>>>> *CfgHpi = 0x2;
>>>> *adrmsb = 0x80;
>>>> *adrnmsb = 0x0;
>>>> *CfgHpi = 0x3;
>>>> *Hpic = 0x00;
>>>> *Gpioen = 0x1e4c;
>>>> *pwremu = 0x1;
>>>>
>>>> for(i=0;i<16;i++){
>>>> *memory++ = i;
>>>> }
>>>>
>>>> while(1);
>

Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467 Start a New Thread