RTL8019AS 16bit mode

Hello,

I have built a device based on Renesas' H8/3068F and RTL8019AS. I have connected the chips in the following way: H8/3068F RTL8019AS Notes

-------- --------- ----- A[0-9] A[0-9] other Realtek's address lines tied to GND D[8-15] SD[0-7] D8SD0, D9SD1, etc. D[0-7] SD[8-15] /CS4 AEN /HWR, /LWR IOWB connected through HC08 (AND) gate /RD IORB /WAIT IOCHRDY line pulled up through 10k /IRQ0 INT0 SLOT16 pulled down though 27k In this HW configuration 8019AS has been working in 8 bit mode very well for a few months.

Last week I wanted to test Realtek's 16 bit mode (i.e. word-wide DMA transfers). The only change I made in the hardware was removing

27k resistor and pulling up SLOT16 pin through 360 ohm - just like in a 16bit slot of a PC's motherboard. Then I switched MCU data bus into 16bit mode (by apropriate ABWCR register setting) and started playing with Realtek's registers, especially with the bit WTS of the DCR. Unfortunately, without success. When I read even address, upper byte was expected register value and lower byte was 0xff. But when I read even address, I always got 0xffff. The interesting thing is that 8019 still works well in 8bit mode when SLOT16 is pulled up.

Does anyone know how to force 8019AS to work in 16bit mode? I am looking for any hints, source code, schematics, etc. Any help will be appreciated.

Regards, /J.D.

--
Jan Dubiec, jdx@slackware.pl, mobile: +48 602 101787

G³êboka wiara wymaga p³ytkiego rozumu i nik³ej wiedzy.
Reply to
Jan Dubiec
Loading thread data ...

In my experience, it's all in the software, and DCR bit 0 (WTS) is the key. I've left IOCS16 (SLOT16) floating with no effect (as have other designs). With as little as A[0-4], SD[0-15], IOWR, IORD, IOCHRDY you're good to go.

Registers use 8-bit access regardless. Have you tried your test with the buffer ring instead? Have you just tried a regular transmission, sending 16 bits per I/O instead of 8?

As for init, the DCR value gets set immediately after after stopping the NIC for 1.6mS to reset it. Are you stopping the NIC first during init, and are you waiting the spec 1.6mS before proceeding?

FYI, some suggestions to save MCU pins: you only need the lower 5 pins to address the 8019AS; you can hardwire the rest unless you're using a shared address bus. Likewise, AEN can be wired low. As long as you don't strobe IORD or IOWR, you can share all the SA and SD lines with other purposes.

For some schematics, you could check out the AVR implementation of the RTL8019AS at

formatting link
among many others. However, you'll find that many implementations omit CHRDY wiring, which is hazardous.

formatting link
may also be a useful reference, as they sell 8019AS proto boards.

Reply to
Richard

On Mon, 17 Nov 2003 20:26:28 -0700, Richard wrote: [.....]

That's it! Thanks for the suggestion. Now 16 bit mode works very well. Although I have found one strange thing which I cannot understand. Assuming that during normal operation MCU's data bus width is 16 bit, I have to switch the bus into 8 bit mode when accessing 8019AS registers and then switch back into 16 bit. This is not a real problem because such a switch is only one "set bit" or "clear bit" instruction (~ 90ns in my system), but I consider it to be strange and non elegant.

No, I hadn't. I had tested only byte or only word access to resisters/DMA but not "mixed mode".

Yes, I know those tricks.

Yes, I know it. In my design I have connected this signal to MCU's /WAIT pin in order to use MCU's bus controller features instead of playing with IOCHRDY "manually" like it is done in other projects. From my experience, I can also add that IOCHRDY has to be pulled up. Without a pull up resistor I had observed really strange behaviour.

Regards, /J.D.

--
Jan Dubiec, jdx@slackware.pl, mobile: +48 602 101787

G³êboka wiara wymaga p³ytkiego rozumu i nik³ej wiedzy.
Reply to
Jan Dubiec

Not strange when you consider the part was designed for the ISA bus. When an 8-bit register was accessed, the chip would de-assert IOCS16/ and the bus would automagically run an 8-bit cycle.

Reply to
Jim Stewart

Glad to hear it!

No. Just use 0's for the high byte during writes and ignore the high byte when you do a read. This works like a charm for me, so there's no need to switch I/O modes. Then again, I'm not using a memory interface on the MCU, I'm bit-banging GPIO ports, so I might have more flexibility in the handling. I also enable pull-ups on the data ports during reads, FWIW.

The implementations I've seen have just been so slow in their I/O routines that they never encountered the problem (though they will as they upgrade to faster MCUs). If you use tight I/O code, or a hardware I/O interface that is even faster, you cannot ignore CHRDY.

Having a hardware WAIT line is a nice luxury; I had to use an ISR, but it's still very efficient (particularly since CHRDY only gets pulled low ~10% of the time in my testing).

Yes, I would expect so since it would float when not being driven low, causing WAIT to be triggered incorrectly during non-blocked I/Os. I can't say I've seen this problem, since I used an internal MCU pull-up from the beginning.

I'm very happy the suggestion helped. Please post a comment on the suggestion for 16-bit access to 8-bit registers - I'm interested to hear if it works for you too.

Regards, Richard

Reply to
Richard

On Wed, 19 Nov 2003 23:30:51 -0700, Richard wrote: [.....]

[.....]

It won't work. It's a shame - I have been working with this HW for over three months, but just a few hours ago I found in the "H8/3068F Hardware Manual" following information: "The H8/300H CPU can access word data and longword data on memory, but word or longword data must begin at an even address. If an attempt is made to access word or longword data at an odd address, no address error occurs but the least significant bit of the address is regarded as 0, so the access starts at the preceding address. This also applies to instruction fetches."

This is exactly what my tests have showed. Now all is clear for me. It was quite interesting problem. ;-)

Regards, /J.D.

--
Jan Dubiec, jdx@slackware.pl, mobile: +48 602 101787

G³êboka wiara wymaga p³ytkiego rozumu i nik³ej wiedzy.
Reply to
Jan Dubiec

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.