Forums

Can't observe high level on address line

Started by xuhe...@yahoo.com August 1, 2010
I’m using SEED-DEC6713 developing board (TMS320C6713) to control an A/D chip and two D/A chips through a FPGA (Actel ProAsic3 A3p250). And the FPGA is connected with DSP through EMIF interface. The detailed processes of A/D and D/A are controlled by FPGA, DSP only needs to tell FPGA when to run A/D or D/A. This work has been helped by Jeff Brower in this forum last summer .
We use 3 address lines for controlling FPGA:
EA18 is used for D/A write-enable.
EA16 is the start signal of A/D sampling.
EA20 is used for A/D read-enable.
In DSP program, I use following codes for doing this:
#include
#include
#include
#include
#include
#include
#include
#include
#include "myEdma.h"
void main()
{
CSL_init();
DEC6713_init();
unsigned int temp;
temp=*((volatile unsigned short int*)0xA0040000);/*EA18,W_en */

temp=*((volatile unsigned short int*)0xA0010000);/*EA16, start signal of A/D sampling */

temp=*((volatile unsigned short int*)0xA0100000);/*EA20,R_en */
}
When running code in CCS2.2 step by step (pressing F10), I also use a logic analyzer to observe these 3 signals. But I can only see /CE0 is low and can’t observe any high level on EA18/ EA16/ EA20. These 3 address lines are always low. FPGA can’t receive any instruction for work.
If I change these addresses to 0xB0040000 0xB0010000 0xB0100000, I can observe high levels on EA18/ EA16/ EA20. Because SEED-DEC6713 has a USB2.0 (0xB0040000~0xB004000F) and two UART (0xB0080000~0xB008000F, 0xB00C0000~0xB00C000F), if I use above addresses, the desirable data will be sent to wrong device.
PS: The cectl register of /CE2 (0xA0000000~0xAFFFFFFF) has been set into its default values.
It is so strange and I don’t know why. Could there anyone help me? Thx a lot!!

_____________________________________
Xu-

> I'm using SEED-DEC6713 developing board (TMS320C6713) to control an A/D chip and two D/A chips through a FPGA (Actel
> ProAsic3 A3p250). And the FPGA is connected with DSP through EMIF interface. The detailed processes of A/D and D/A are
> controlled by FPGA, DSP only needs to tell FPGA when to run A/D or D/A. This work has been helped by Jeff Brower in
> this forum last summer .
> We use 3 address lines for controlling FPGA:
> EA18 is used for D/A write-enable.
> EA16 is the start signal of A/D sampling.
> EA20 is used for A/D read-enable.
> In DSP program, I use following codes for doing this:
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include "myEdma.h"
> void main()
> {
> CSL_init();
> DEC6713_init();
> unsigned int temp;
> temp=*((volatile unsigned short int*)0xA0040000);/*EA18,W_en */
> …
> temp=*((volatile unsigned short int*)0xA0010000);/*EA16, start signal of A/D sampling */
> …
> temp=*((volatile unsigned short int*)0xA0100000);/*EA20,R_en */
> }
> When running code in CCS2.2 step by step (pressing F10), I also use a logic analyzer to observe these 3 signals. But I
> can only see /CE0 is low and can't observe any high level on EA18/ EA16/ EA20. These 3 address lines are always low.
> FPGA can't receive any instruction for work.
> If I change these addresses to 0xB0040000 0xB0010000 0xB0100000, I can observe high levels on EA18/ EA16/ EA20.
> Because SEED-DEC6713 has a USB2.0 (0xB0040000~0xB004000F) and two UART (0xB0080000~0xB008000F,
> 0xB00C0000~0xB00C000F), if I use above addresses, the desirable data will be sent to wrong device.
> PS: The cectl register of /CE2 (0xA0000000~0xAFFFFFFF) has been set into its default values.
> It is so strange and I don't know why. Could there anyone help me? Thx a lot!!

How do you know the default value of CECTL2 is correct? Did you look in your .gel file to see what register bits are
being set for CE3 space? As a first step, whatever CE3 is using, suggest you try that for CE2. As a second step,
suggest to carefully study EMIF asynchronous memory setup and be sure you understand exactly which values to set, and
why (no guessing). The C6x EMIF reference guide is here:

http://focus.ti.com/lit/ug/spru266e/spru266e.pdf

-Jeff

_____________________________________
Jeff:
Thanks for your reply.
I'll follow your advice for next work and at last I'll post the final result.

I’m using SEED-DEC6713 developing board (TMS320C6713) to control an A/D chip and two D/A chips through a FPGA (Actel ProAsic3 A3p250). And the FPGA is connected with DSP through EMIF interface. The detailed processes of A/D and D/A are controlled by FPGA, DSP only needs to tell FPGA when to run A/D or D/A. This work has been helped by Jeff Brower in this forum last summer .
>We use 3 address lines for controlling FPGA:
>EA18 is used for D/A write-enable.
>EA16 is the start signal of A/D sampling.
>EA20 is used for A/D read-enable.
>In DSP program, I use following codes for doing this:
>#include
>#include
>#include
>#include
>#include
>#include
>#include
>#include
>#include "myEdma.h"
>void main()
>{
> CSL_init();
> DEC6713_init();
>unsigned int temp;
> temp=*((volatile unsigned short int*)0xA0040000);/*EA18,W_en */
>…
> temp=*((volatile unsigned short int*)0xA0010000);/*EA16, start signal of A/D sampling */
>…
> temp=*((volatile unsigned short int*)0xA0100000);/*EA20,R_en */
>}
>When running code in CCS2.2 step by step (pressing F10), I also use a logic analyzer to observe these 3 signals. But I can only see /CE0 is low and can’t observe any high level on EA18/ EA16/ EA20. These 3 address lines are always low. FPGA can’t receive any instruction for work.
> If I change these addresses to 0xB0040000 0xB0010000 0xB0100000, I can observe high levels on EA18/ EA16/ EA20. Because SEED-DEC6713 has a USB2.0 (0xB0040000~0xB004000F) and two UART (0xB0080000~0xB008000F, 0xB00C0000~0xB00C000F), if I use above addresses, the desirable data will be sent to wrong device.
>PS: The cectl register of /CE2 (0xA0000000~0xAFFFFFFF) has been set into its default values.
>It is so strange and I don’t know why. Could there anyone help me? Thx a lot!!
>
>_____________________________________

_____________________________________
'xuhengying',


I assume that you are still having your problem and I think that I
understand your information [I may not understand it correctly].

A comment on problem description -
Q1..Is the following a correct statement??
"For the test CE2 & CE3 are initialized are initialized to 0x22a28a22. The
test program works using CE3 [base address == 0xB0000000] but does not work
using CE2 [base address == 0xA0000000]."
a..If the above statement is true [and you have set up everything
correctly], then you have a hardware problem related to CE2. If there are
address line buffers for EA16, 18, 20 [I think that there might be], they
are probably enabled by [or should be enabled by] 'CE2 OR CE3'.
b..If the above statement is not true, you should run your tests with the
same setting for CE2 and CE3.
Q2..What happens when you run the same test with CE2 and CE3 initialized to
0x22a28a22 with the ONLY difference being the base address??? [0xA0000000
vs. 0xB0000000]

mikedunn

On Wed, Aug 4, 2010 at 4:12 AM, wrote:

> Jeff:
> Thanks for your reply.
> I'll follow your advice for next work and at last I'll post the final
> result.
>
> Im using SEED-DEC6713 developing board (TMS320C6713) to control an A/D
> chip and two D/A chips through a FPGA (Actel ProAsic3 A3p250). And the FPGA
> is connected with DSP through EMIF interface. The detailed processes of A/D
> and D/A are controlled by FPGA, DSP only needs to tell FPGA when to run A/D
> or D/A. This work has been helped by Jeff Brower in this forum last summer .
> >We use 3 address lines for controlling FPGA:
> >EA18 is used for D/A write-enable.
> >EA16 is the start signal of A/D sampling.
> >EA20 is used for A/D read-enable.
> >In DSP program, I use following codes for doing this:
> >#include
> >#include
> >#include
> >#include
> >#include
> >#include
> >#include
> >#include
> >#include "myEdma.h"
> >void main()
> >{
> > CSL_init();
> > DEC6713_init();
> >unsigned int temp;
> > temp=*((volatile unsigned short int*)0xA0040000);/*EA18,W_en */
> >
> > temp=*((volatile unsigned short int*)0xA0010000);/*EA16, start signal
> of A/D sampling */
> >
> > temp=*((volatile unsigned short int*)0xA0100000);/*EA20,R_en */
> >}
> >When running code in CCS2.2 step by step (pressing F10), I also use a
> logic analyzer to observe these 3 signals. But I can only see /CE0 is low
> and cant observe any high level on EA18/ EA16/ EA20. These 3 address lines
> are always low. FPGA cant receive any instruction for work.
> > If I change these addresses to 0xB0040000 0xB0010000 0xB0100000, I
> can observe high levels on EA18/ EA16/ EA20. Because SEED-DEC6713 has a
> USB2.0 (0xB0040000~0xB004000F) and two UART (0xB0080000~0xB008000F,
> 0xB00C0000~0xB00C000F), if I use above addresses, the desirable data will be
> sent to wrong device.
> >PS: The cectl register of /CE2 (0xA0000000~0xAFFFFFFF) has been set into
> its default values.
> >It is so strange and I dont know why. Could there anyone help me? Thx a
> lot!!
> >
> >_____________________________________
> >
> >
>
>
> _____________________________________
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Mike Dunn:
"For the test CE2 & CE3 are initialized are initialized to 0x22a28a22. The test program works using CE3 [base address == 0xB0000000] but does not work using CE2 [base address == 0xA0000000].">
When I checked my ce2ctl register, its value was set into 0x02208812 by mistake. Then I modified it into 0x22a28a22. After that, when using 0xA0040000 /0xA0010000/0xA0040000 [base address == 0xA0000000], I can observe high level on EA18/EA16/EA20 and read right data on these addresses. The problem has been solved. Thanks!
But I still don't know why address line is influenced by cectl register. According to my understanding, cectl register only plays an important part in reading/writing data and EA lines are output pins. When I use following instructions:
temp=*((volatile unsigned short int*)0xA0040000);/*EA18,W_en */
EA18 should output a high level , whatever cectl value is.
My second question: Why is 0x22a28a22 the ce2ctl's default value? According to Figure 3-16 on spru266e.pdf , its default value should be 0xffffff23. But if ce2ctl register is changed into 0xffffff23, I can’t get right data from data bus.

I feel it very difficult to answer this question because:
1. SEED-DEC6713 has a Board Controlling Register(DECCTL) on 0xB0000000 and it maps USB2.0 and two UARTs into 0xB0040000~0xB00C000F.
2. SEED-DEC6713 maps 4 storage spaces /XCE[3:0] into /CE2 and /CE3 of C6713 for user’s extension with the help of EA[21:19]. For example, /XCE0 is mapped into 0xA0000000~0xA03FFFFF and 0xB0200000~0xB027ffff.
CE2 and CE3 are initialized to 0x22a28a22 and I run this in CCS2.2:
temp=*((volatile unsigned short int*)0xA0000000);
temp=*((volatile unsigned short int*)0xB0000000);
When the first sentence is carried out, I get right data 0xD17 and /XCE0 is low. But after the second sentence is carried out, I get wrong data 0xD00 and /XCE0 is low.

In current design, FPGA has a FIFO for A/D or D/A data storage. FPGA is connected to DSP through EMIF. We use /ARE for reading clock and /AWE for writing clock respectively. ED[13:0] is data line. EA18 is for FIFO Wring_enable and EA20 is for FIFO Reading_enalbe.
FPGA doesn’t use /CE0 pin (though the pin has been connected to EMIF) for FIFO reading or writing because my partner (he is in charge of hardware design and FPGA programming) thinks EA18/EA20 can play the same role as /CE0. If no using /CE0, which address should I send for data reading/ writing? Many designs for DSP and FPGA use this pin. Besides, I’m not sure whether this kind of design can work properly and I can’t find any other reason to convince him because we both are newcomers.
Thanks for reading so long post!!

_____________________________________
xuhengying,

On Thu, Aug 5, 2010 at 5:56 AM, wrote:

> Mike Dunn:
> > "For the test CE2 & CE3 are initialized are initialized to 0x22a28a22. The
> test program works using CE3 [base address == 0xB0000000] but does not work
> using CE2 [base address == 0xA0000000].">
> When I checked my ce2ctl register, its value was set into 0x02208812 by
> mistake. Then I modified it into 0x22a28a22. After that, when using
> 0xA0040000 /0xA0010000/0xA0040000 [base address == 0xA0000000], I can
> observe high level on EA18/EA16/EA20 and read right data on these addresses.
> The problem has been solved. Thanks!
> But I still don't know why address line is influenced by cectl register.
> According to my understanding, cectl register only plays an important part
> in reading/writing data and EA lines are output pins.


Your understanding is partially correct.
EMIF = External Memory InterFace
All of the pins work together to to perform external memory accesses. The
definition and behavior of these pins is based on the value written to the
CExCTL register.
If you truly want to understand 'why', then all that you have to do is read
the EMIF doc, see what configuration that your '0x0220881' value generated,
and lookup the 'definition and behavior of the EA pins for that
configuration. If you have a question, I will be glad to help.

When I use following instructions:
> temp=*((volatile unsigned short int*)0xA0040000);/*EA18,W_en */
> EA18 should output a high level , whatever cectl value is.
>

That is not a correct assumption based on the documentation.
> My second question: Why is 0x22a28a22 the ce2ctl's default value? According
> to Figure 3-16 on spru266e.pdf , its default value should be 0xffffff23. But
> if ce2ctl register is changed into 0xffffff23, I cant get right data from
> data bus.
>

The '0xffffff23' is a 'power on reset value' normally used by CE1 for
booting. If you look up the bits, you will find that the interface is set
for what I call 'Maximum Slow'.
You should assume that the ONLY valid 'usable without setting it up
configuration' [IMO] is the CE1CTL 'boot mode' configuration.
You should always explicitly configure your EMIF for your hardware - just
like you would configure a serial port or timer.

> to 0x22a28a22 with the ONLY difference being the base address??? [0xA0000000
> vs. 0xB0000000]>
> I feel it very difficult to answer this question because:
> 1. SEED-DEC6713 has a Board Controlling Register(DECCTL) on 0xB0000000 and
> it maps USB2.0 and two UARTs into 0xB0040000~0xB00C000F.
> 2. SEED-DEC6713 maps 4 storage spaces /XCE[3:0] into /CE2 and /CE3 of C6713
> for users extension with the help of EA[21:19]. For example, /XCE0 is
> mapped into 0xA0000000~0xA03FFFFF and 0xB0200000~0xB027ffff.
> CE2 and CE3 are initialized to 0x22a28a22 and I run this in CCS2.2:
> temp=*((volatile unsigned short int*)0xA0000000);
> temp=*((volatile unsigned short int*)0xB0000000);
> When the first sentence is carried out, I get right data 0xD17 and /XCE0 is
> low. But after the second sentence is carried out, I get wrong data 0xD00
> and /XCE0 is low.
>

All of this depends on how the SEED board has been designed. [assuming that
it is SEED supplied decoding]
I don't understand your test. You read from 2 different addresses and you
got different data.
Q1.. What are you trying to accomplish??


> In current design, FPGA has a FIFO for A/D or D/A data storage. FPGA is
> connected to DSP through EMIF. We use /ARE for reading clock and /AWE for
> writing clock respectively. ED[13:0] is data line. EA18 is for FIFO
> Wring_enable and EA20 is for FIFO Reading_enalbe.
> FPGA doesnt use /CE0 pin (though the pin has been connected to EMIF) for
> FIFO reading or writing because my partner (he is in charge of hardware
> design and FPGA programming) thinks EA18/EA20 can play the same role as
> /CE0.


Your partner is NOT correct. Tell him to read the last few lines of the
'memory map' in the 6713 data sheet. It is obvious that CE0-3 are decoded
from address bits 28-31 inside the DSP.
If you do not use a CEx for decode, your device will respond to memory
accesses in every CE space. For example, if you write to a UART at
0xB0040000, you will also write to the FIFO.
> If no using /CE0, which address should I send for data reading/ writing?


I am not sure if you are speaking of 'CE0' from the DSP or 'XCE0' from an
FPGA.
1. Addresses should have been defined before you started.
2. Theoretically [and realistically] there are NO safe addresses without
using one of the CE0-3 lines from the DSP. That is exactly why they were
created.

My thoughts:
1. Use CE2 as an enable.
2. In order to make minimal changes to your design use '/CE2' anded with
'EA18' for write enable and '/CE2' anded with 'EA20' for read enable.
3. This will properly access for adresses 0xA0040000 /0xA0010000.
> Many designs for DSP and FPGA use this pin. Besides, Im not sure whether
> this kind of design can work properly and I cant find any other reason to
> convince him because we both are newcomers.
>

You are correct - you need a CE line.

mikedunn

> Thanks for reading so long post!!
>
>
>
> _____________________________________
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
mikedunn
Thanks for your detailed reply!

According to EMIF doc(spru266e), if CE2CTL is set to'0x02208812', I get following results:
WRSETUP->0 WRSTRB->4 WRHLD->2
RDSETUP->0 TA->2 RDSTRB->8
MTYPE->ASYNC16 RDHLD->2
According to definitions that SETUP and HOLD values are related to EA, so I guess maybe the wrong values cause that high levels can’t be observed when reading. Is my understanding correct? But I don’t know how to verify it by using a logic analyzer.

The aim of this test was to find the difference between 0xA0000000 and 0xB0000000. But unfortunately, I couldn’t get any valuable information because SEED had a Board Controlling Register(DECCTL) on 0xB0000000. Will you please give me some advice?
< My thoughts:
1. Use CE2 as an enable.
2. In order to make minimal changes to your design use '/CE2' anded with 'EA18' for write enable and '/CE2' anded with 'EA20' for read enable.
3. This will properly access for adresses 0xA0040000 /0xA0010000.>
Thanks for your advice. We both are modifying our design. If there are any other questions, I’ll post here.

_____________________________________
xuhengying,

On Sun, Aug 8, 2010 at 5:47 AM, wrote:

> mikedunn
> Thanks for your detailed reply!
> > read the EMIF doc, see what configuration that your '0x0220881' value
> generated, and lookup the 'definition and behavior of the EA pins for that
> configuration.>
> According to EMIF doc(spru266e), if CE2CTL is set to'0x02208812', I get
> following results:
> WRSETUP->0 WRSTRB->4 WRHLD->2
> RDSETUP->0 TA->2 RDSTRB->8
> MTYPE->ASYNC16 RDHLD->2
> According to definitions that SETUP and HOLD values are related to EA, so I
> guess maybe the wrong values cause that high levels cant be observed when
> reading. Is my understanding correct? But I dont know how to verify it by
> using a logic analyzer.
>

You are experiencing a common "comprehension problem" that many people who
have experience with micros or who have been taught with traditional
documentation. The EMIF is programmable - and because of this the definition
of the EA pins can change. It is spelled out in the documentation, but many
folks miss it [including experienced hw designers] because it is "just
addressing".
The table below illustrates the 'remapping' of the EA pins for different
address widths.
width,maxSize,pinMapping,typeOfAddress
x8, 1M, EA[21:2]==A[19:0], Byte address
x16, 2M, EA[21:2]==A[20:1], Halfword address
x32, 4M, EA[21:2]==A[21:2], Word address

For example, I will use a target address of 4 [0x04, 0100b] to show the
changes.
x32 mem, EA2 is high
x16 mem, EA3 is high
x8 mem, EA4 is high

mikedunn
> > got different data. Q1.. What are you trying to accomplish??>
> The aim of this test was to find the difference between 0xA0000000 and
> 0xB0000000. But unfortunately, I couldnt get any valuable information
> because SEED had a Board Controlling Register(DECCTL) on 0xB0000000. Will
> you please give me some advice?
> < My thoughts:
> 1. Use CE2 as an enable.
> 2. In order to make minimal changes to your design use '/CE2' anded with
> 'EA18' for write enable and '/CE2' anded with 'EA20' for read enable.
> 3. This will properly access for adresses 0xA0040000 /0xA0010000.>
> Thanks for your advice. We both are modifying our design. If there are any
> other questions, Ill post here.
>
>
>
> _____________________________________
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php