Below is a posting I made on the Softools WinIDE group, I have posted
it here because I think the possible fault may apply to DC as well as
Softools as they or both based on the same TCPIP stack.
Regards
Martin Honeywill
---------------------------------
I've been trying to track down intermittent ethernet comms errors with
our application. We are using an RCM3200 which has an ASIX NIC.
We have a VB app using UDP to talk to a handfull of RCM3200's. We have
noticed that we were getting intermittent comms errors, packet
timeouts and corrupted packets.
What we also noticed was that the rabbits were chattering away on the
network for no appaternt reason. This was indicated by flashing of the
activity lights on our switch.
I did the following things to investigate
1. I used Ethereal to monitor the bus, there was no traffic, it was
silent.
2. I changed the application to be a the static.c exsample supplied by
rabbit. This made no difference, I was still getting flashing activity
lights.
3. I removed all other devices from the network apart from one rabbit.
The activity light was still flashing.
4. I used two 10/100 switches a Netgear and a 3com. The effect was the
same. The activity light was still flashing.
5. I connected the Rabbit to my Compaq laptop which has a 10/100/1000
port. The activity light on this port was flashing away just like the
switches.
6. I connected the rabbit to an old netgear DS516 10/100 HUB this
indicated continious activity and the collision light was flashing.
7. I eventually connected the rabbit to a 10M Hub. This seemed to fix
the problem (No flashing Activity lights on the hub). I then connected
up our system and downloaded our code and its been running for the
last few hours without a fault.
I was also able to halt the code in the rabbit, and the switch
activity light would still be flashing away. This makes me think it is
a ASIX auto negotiation problem.
The activity light on the Rabbit does NOT flash away light the
activity lights on the switches.
Has anyone else experienced similar problems or noticed RCM3200 boards
chattering away when connected to 10/100 ports on switches or hubs.
It looks like the 10/100 autonegotiation of the ASIX chip is not
working correctly, or not configured correctly.
What I need to do now is work out how to switch the ASIX chip into 10M
mode. The Rabbit NIC initialiastion code is all written in assembler
(Why?? its not time critical). Has anyone modified these registers on
an ASIX chip, do they know how to do it? it looks complex at a first
glance.
Any toughts or observations would be appreciated.
Regards
Martin Honeywill
Possible problem with Ethernet Autonegotiation on an RCM3200 (ASIX NIC Chip)
Started by ●April 28, 2006
Reply by ●April 30, 20062006-04-30
Thanks Kelly for your reply.
Below is a Snip from a reply on the WINIDE group, it looks like there
could have been a batch problem on the RCM3200's. I will contact
Zworld and keep this group updated.
Has anyone on this group ever forced the ASIX chip into a 10M mode via
software? If so would they be willing to share the code?
DC does not seem to have any API calls for forcing the Data rates /
Duplex mode. As you say "Shame on them"
Cheers
Martin Honeywill
PS Goodluck with the Procurve replacement plan ;-)
******** From WinIDE Group ******************
Thanks Mark
I appreciate the fast reply.
I Tried the Software fix, after checking what it was for in the Erata
for the ASIX chip. Unfortunatly this made no difference.
> The version of the ASIX lib code I have did not hold the reset line
>long enough.
But I managed to find an old RCM3200 and ran my tests on that, and it
worked correctly. Therefore your description of a hardware batch fault
seems to be what we are experiencing.
How did you discover the fault? do you know if Zworld ever published
any info on it? I will contact Zworld to try and find the faulty Batch
numbers.
Meanwhile, if I can work out how the ASIX chip works I will try and
force it into 10M mode to see if this makes any difference.
Cheers
Martin Honeywill
--- In w..., "Mark Davis" wrote:
>
> Two possibly related issues that I know of with the RCM3200:
> First, a hardware problem:
>
> The first batch of RCM3200's we bought had a problem with the
Ethernet port. We had to ship all of our first ones back (50 or so?)
to have some capacitors and a resistor or two replaced with different
values. The values they originally used caused a problem with 100Mbit
switches where they would drop all kinds of packets and not negotiate
the connection properly. If you plug it in to a 10Mbit HUB (NOT a
switch), and it works fine, then this may very well be the problem (or
at least part of it).
>
> Unfortunately I don't know how to tell if you have one of the
affected boards (except to call ZWorld and ask if the lot # on your
board is one of the ones with the problem).
******** Enod of Snip from WinIDE Group ******************
--- In r..., "Kelly" wrote:
>
> --- In r..., "Martin Honeywill"
> wrote:
> >
> > Below is a posting I made on the Softools WinIDE group, I have
> > posted it here because I think the possible fault may apply to
> > DC as well as Softools as they or both based on the same TCPIP
> > stack.
>
> This looks like a problem with the auto-detect algorithms between the
> ASIX mac and the hub/switch upstream. My company's oldr products that
> use an Intel i82563ET 10/100 mac will exhibit the same problem when
> they are connected to low-end NetGear switches and hubs.
>
> The only workaround I know for this is to disable able-detect and hard
> code in the speed and duplex setting for the link. If DC doesn't have
> API calls for this, shame on them. I've tried writing code on our
> appliance that detects when its 10/100 port has gone wacko, but its
> hard to detect solely by looking at the mac's registers.
>
> My company's IT setup uses quite a few of the larger NetGear switches,
> and it's not uncommon for a cascade of auto-detect storms to saturate
> our in-house backbone. When I'm the only guy around to fix this
> problem, I yank power cords from the switches with the most blinking
> lights on the front ;) They usually are fine after power comes back.
> Secretly, I hope that I break the switch so we can replace it with an
> HP ProCurve.
>
> Kelly
>
Below is a Snip from a reply on the WINIDE group, it looks like there
could have been a batch problem on the RCM3200's. I will contact
Zworld and keep this group updated.
Has anyone on this group ever forced the ASIX chip into a 10M mode via
software? If so would they be willing to share the code?
DC does not seem to have any API calls for forcing the Data rates /
Duplex mode. As you say "Shame on them"
Cheers
Martin Honeywill
PS Goodluck with the Procurve replacement plan ;-)
******** From WinIDE Group ******************
Thanks Mark
I appreciate the fast reply.
I Tried the Software fix, after checking what it was for in the Erata
for the ASIX chip. Unfortunatly this made no difference.
> The version of the ASIX lib code I have did not hold the reset line
>long enough.
But I managed to find an old RCM3200 and ran my tests on that, and it
worked correctly. Therefore your description of a hardware batch fault
seems to be what we are experiencing.
How did you discover the fault? do you know if Zworld ever published
any info on it? I will contact Zworld to try and find the faulty Batch
numbers.
Meanwhile, if I can work out how the ASIX chip works I will try and
force it into 10M mode to see if this makes any difference.
Cheers
Martin Honeywill
--- In w..., "Mark Davis" wrote:
>
> Two possibly related issues that I know of with the RCM3200:
> First, a hardware problem:
>
> The first batch of RCM3200's we bought had a problem with the
Ethernet port. We had to ship all of our first ones back (50 or so?)
to have some capacitors and a resistor or two replaced with different
values. The values they originally used caused a problem with 100Mbit
switches where they would drop all kinds of packets and not negotiate
the connection properly. If you plug it in to a 10Mbit HUB (NOT a
switch), and it works fine, then this may very well be the problem (or
at least part of it).
>
> Unfortunately I don't know how to tell if you have one of the
affected boards (except to call ZWorld and ask if the lot # on your
board is one of the ones with the problem).
******** Enod of Snip from WinIDE Group ******************
--- In r..., "Kelly" wrote:
>
> --- In r..., "Martin Honeywill"
> wrote:
> >
> > Below is a posting I made on the Softools WinIDE group, I have
> > posted it here because I think the possible fault may apply to
> > DC as well as Softools as they or both based on the same TCPIP
> > stack.
>
> This looks like a problem with the auto-detect algorithms between the
> ASIX mac and the hub/switch upstream. My company's oldr products that
> use an Intel i82563ET 10/100 mac will exhibit the same problem when
> they are connected to low-end NetGear switches and hubs.
>
> The only workaround I know for this is to disable able-detect and hard
> code in the speed and duplex setting for the link. If DC doesn't have
> API calls for this, shame on them. I've tried writing code on our
> appliance that detects when its 10/100 port has gone wacko, but its
> hard to detect solely by looking at the mac's registers.
>
> My company's IT setup uses quite a few of the larger NetGear switches,
> and it's not uncommon for a cascade of auto-detect storms to saturate
> our in-house backbone. When I'm the only guy around to fix this
> problem, I yank power cords from the switches with the most blinking
> lights on the front ;) They usually are fine after power comes back.
> Secretly, I hope that I break the switch so we can replace it with an
> HP ProCurve.
>
> Kelly
>
