Anybody here got a Xilinx ML605?

[pfraser]

I'm having trouble running the application described in
XAPP740 (Designing high-performance video systems with the
AXI interconnect).

I have tried running the pre-built images, and building my own.
In both cases it seems to hang during the initialization of
the DVI transmitter.

If I just run the software it sometimes sends out a few bytes
to the DVI transmitter before it hangs; sometimes it hangs
endlessly pulsing SCL before it sends out any valid data.

If I debug the software it invariably hangs waiting for the busy
bit in the status register (during the first invocation of
XIic_DynSend. The core is the AXI IIC Bus Interface (v1.01a).

One thing I noticed is that, while SCL always gets down to
0V, SDA sometimes gets to 0V, and sometimes only to 0.6V.
I have no idea why this might be, as I see this when the
V6 should be driving.

I have verified that the demo images that the board is shipped
with seem to work correctly. On reset I get the Xilinx splash
screen, and a reasonable sequence of IIC writes and reads to
the DVI transmitter. I still some weak lows though.

Anybody else working with XAPP740? Any idea what might be wrong?
I asked in the Xilinx forums, but received a thundering silence.

Thanks

Pete

 

[Morten Leikvoll]

"pfraser" <pete_fraser@comcast.net> wrote in message
news:jhfeln$79b$1@dont-email.me...

I'm having trouble running the application described in
XAPP740 (Designing high-performance video systems with the
AXI interconnect).

I dont know much about this project, but something about i2c captured my
attention.

One thing I noticed is that, while SCL always gets down to
0V, SDA sometimes gets to 0V, and sometimes only to 0.6V.
I have no idea why this might be, as I see this when the
V6 should be driving.

There are several possible reasons why SDA don't go all the way down. Here
are two common ones.
1.High drive (somthing is driving the SDA high instead of using "releasing"
it with a open drain drive). Only bad hw implementations does this.
2.Long wires. If something at the end of a long wire pulls down, there will
be a voltage drop at the receiver. This happens typically when communicating
with a DVI monitor over the DDC bus.

 

[Morten Leikvoll]

Oh, and I can add:
A pulsing SCL can indicate that the master is trying to get SDA high so it
can make a start/stop. If any slave or design error is holding SDA low,
there can be no start/stop condition. This is why all i2c initiation should
start with a up to 9 clock loop looking for SDA=high before sending a stop.
Some implementation may be lazy and loop forever instead of giving up with
an error msg.
No devices will hold SDA for more than 8 clks wich makes this a guaranteed
start condition.
Also notice that if you hotplug i2c devices (like monitors with DDC bus),
there is no guaranee that slaves are in stopped state when you attach them
unless you do this init cycle. If a slave happened to be in the middle of
something, got disconnected but kept its power, then reconnected later in
the middle of something else, you will get conflict. This can only be solved
by proper init.

 

[pfraser]

Morten Leikvoll wrote:

"pfraser"<pete_fraser@comcast.net> wrote in message

One thing I noticed is that, while SCL always gets down to
0V, SDA sometimes gets to 0V, and sometimes only to 0.6V.

There are several possible reasons why SDA don't go all the way down. Here
are two common ones.
1.High drive (somthing is driving the SDA high instead of using "releasing"
it with a open drain drive). Only bad hw implementations does this.

I haven't yet looked at the HDL. I'll do that next.

2.Long wires. If something at the end of a long wire pulls down, there will
be a voltage drop at the receiver. This happens typically when communicating
with a DVI monitor over the DDC bus.

That was my first thought, but I still get the bad low even
with the monitor disconnected.

Thanks

Pete

 

[pfraser]

Morten Leikvoll wrote:

Oh, and I can add:
A pulsing SCL can indicate that the master is trying to get SDA high so it
can make a start/stop. If any slave or design error is holding SDA low,
there can be no start/stop condition. This is why all i2c initiation should
start with a up to 9 clock loop looking for SDA=high before sending a stop.
Some implementation may be lazy and loop forever instead of giving up with
an error msg.

A good clue. I had noticed that, when the unit failed with
the pulsing SCL, it failed before my breakpoint (i.e., earlier
than I expected) and it failed with SDA low-ish. I was triggering
my scope on SCL going low, so I didn't see the SDA go low.
Today I'll trigger on SDA going low, and see when in the SW that
happens. This is all supposed to be tested code, so I was
assuming it is something wrong with my board, but perhaps I'm
being too trusting.

Thanks

Pete