RTL8019AS problems

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.

On Thu, 6 Nov 2003 02:07:03 +1100, "Tony Tsang" wrote: [.....]

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/3068F@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.

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.

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

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.

T> > I'm trying to use RTL8019AS for my embedded project.

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

T> Hello,

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.

the

send

On Thu, 6 Nov 2003 19:22:10 +1100, "Tony Tsang" wrote: [.....] I am sorry for so late answer. I went out for a short vacation.

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.

Regards, /J.D.