Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

RTL8019AS problems

72 views
Skip to first unread message

Tony Tsang

unread,
Nov 5, 2003, 10:07:03 AM11/5/03
to
Hello,

I'm trying to use RTL8019AS for my embedded project. I can initialize the
chip properly, read and write to the registers without any problems, but
when I try to send data to its DMA buffer, it does not work. I tried send
some data to DMA but when I read them back its all 0xFF. Any body have
experience in these? I tried to follow the exact sequence of the ne2000
drivers, but it does not work.

Thanks for your help.

Best regards,

Tony


Gary Kato

unread,
Nov 5, 2003, 5:54:45 PM11/5/03
to
> I tried to follow the exact sequence of the ne2000
>drivers, but it does not work.

The problem might be that the RTL8019AS is not 100% compatible with NE2000.
Just from searching around, it looks like there are MANY cips that say they are
NE2000 compatible, but are not. Try searching Google using RTL8019AS as a
subject. It could be that there are known problems.

Jan Dubiec

unread,
Nov 5, 2003, 10:03:38 PM11/5/03
to
On Thu, 6 Nov 2003 02:07:03 +1100, "Tony Tsang" <to...@silicon.dyndns.org> wrote:
[.....]

> I try to send data to its DMA buffer, it does not work. I tried send
> some data to DMA but when I read them back its all 0xFF.
Did you try to write and then read data to/from the same Realtek's
memory area? It is quite unusual and I am almost sure that it is
impossible. Although I have never tested such case personally. You
have to split Realtek's memory into two separate parts - one for
transmit/output buffer and the other one for receive/input buffer.
This can be accomplished by appropriarte initialization (and
maintenance) of TPSR, PSTART, PSTOP, CURR and BNRY registers.

I suggest downloading AVR port of Adam Dunkels' uIP. It contains
RTL8019AS driver which has surprised me positively. After slight
adjustment to my hardware, it has run properly since the first
compilation. IMO its source is a good tutorial. You can find link to
that port on uIP webpage.

Next, MCU clock speed may be important. I had problems with my
H8/30...@22.1184MHz. In my project I am using OpenTCP and its 8019AS
driver. During normal operation the driver has to switch between
Realtek's register's page 0 and 1 in order to handle CURR and BNRY
registers. Such a switch requires some time so I had to insert
~180ns delays (two nop's) in few places.

Regards,
/J.D.
--
Jan Dubiec, j...@slackware.pl, mobile: +48 602 101787

Głęboka wiara wymaga płytkiego rozumu i nikłej wiedzy.

Tony Tsang

unread,
Nov 6, 2003, 3:22:10 AM11/6/03
to
Hi,

Yes I followed the code in AVR port of uIP. But I need to increment RSAR0
register in order to read properly
from DMA.

I am still not sure what is the problem of the device.

Thanks for your help.

"Jan Dubiec" <j...@slackware.pl> wrote in message
news:87wuaey...@hs001.slackware.pl...

Richard

unread,
Nov 6, 2003, 8:57:46 AM11/6/03
to
Tony Tsang wrote:
> I'm trying to use RTL8019AS for my embedded project.
> I can initialize the chip properly, read and write
> to the registers without any problems, but when I
> try to send data to its DMA buffer, it does not
> work. I tried send some data to DMA but when I read
> them back its all 0xFF. Any body have experience in
> these? I tried to follow the exact sequence of the
> ne2000 drivers, but it does not work.

Particularly for write operations, I found that the RTL8019AS will often
pull CHRDY low. Virtually no drivers I've seen observe this signal, and
it will cause all sorts of DMA write problems if you have tight code.

Drivers I've reviewed seem to avoid the issue by sheer luck - their I/O
signaling routines are slow enough that CHRDY is raised again before
they complete their signaling. (PC drivers are a poor model in this
case because CHRDY is normally handled in PC hardware.)

This may not be your issue, but FYI. A quick hack is to hold /IOWR low
for at least 1000nS during write operations. If you search Google
Groups for RTL8019 CHRDY you'll find prior discussions on this point.

Richard

Tony Tsang

unread,
Nov 6, 2003, 9:42:37 AM11/6/03
to
Hi Richard,

Thanks for the info, my MCU is running at 18.432Mhz, may be i am driving the
chip too fast.
I try to put more delays on the operation to see if it works.


Tony

"Richard" <rh...@azglobal.com> wrote in message
news:3FAA535A...@azglobal.com...

romu

unread,
Nov 6, 2003, 5:35:51 PM11/6/03
to
Hi Tony,

you should'nt try to read back the ring buffer. Instead try to send the
packet on the wire and spy on it what happens.

The ring buffer is logically divided into 2 parts (called 'slots' in the
Linux drivers) : one dedicated to transmitting to the wire and one to
receiving packets from the wire (see .

You will use 1 or 2 TX slots (2 allows back-to-back transmits of
packets) and let the rest for receiving.

romuald

--
Replace nospam with rboudot to answer
Remplacer nospam par rboudot pour répondre

Tony Tsang

unread,
Nov 7, 2003, 1:11:34 AM11/7/03
to
Hi,

Yes I tried to send through the wire and I can see the data is just garbage
or all 0xFF, not what I hvae sent through network.

Tony.
"romu" <nos...@nerim.net> wrote in message
news:v9ieob...@213.41.153.19...

Jan Dubiec

unread,
Nov 11, 2003, 7:44:40 PM11/11/03
to
On Thu, 6 Nov 2003 19:22:10 +1100, "Tony Tsang" <to...@silicon.dyndns.org> wrote:
[.....]
I am sorry for so late answer. I went out for a short vacation.

> Yes I followed the code in AVR port of uIP. But I need to increment RSAR0
> register in order to read properly
> from DMA.

If you want to send/receive an Ethernet frame, you have to initialise
RSAR{0,1} and RBCR{0,1} only once per frame. Into RSAR you write frame
destination/source address in the RTL8019AS memory and frame length
into RBCR. Then you consecutively write/read bytes (or words) to/from
DMA port. That's all.

0 new messages