NE64 w/OpenTCP: Ethernet compatibility problems?

[nerdboy]

Hi Freescale Forum,

We're using the NE64 with OpenTCP. We have the following networking stuff running:

IP
ICMP
UDP
ARP

When we connect the NE64 to our network via a wired router, everything works fine. We can send and receive UDP packets and ping the NE64.

When we connect the NE64 to our network via an WiFi Ethernet Bridge, we are no longer able even to ping the NE64. The LNK, SPD and DUP leds come on on the NE64 side, but the ACT led doesn't come on for a long time and even then there's no communication.

Another device connected to the same WiFi Ethernet Bridge with the same cable works just fine. We've tried other WiFi Ethernet Bridges and found the same problem. I'm 99% sure the problem is with the NE64 and/or OpenTCP.

Has any one come across a similar problem and found a solution? Could this be because the device and software cut corners on the Ethernet spec?

Thanks,

Jeff

[mjbcswitzerland]

Hi Jeff

If the NE64 is programmed to work in auto-negotiation mode you may be having a problem with a PHY bug. See errata MC9S12NE64, Mask 1L19S, Rev. April 12, 2005. Configure to the speed of your bridge and see whether it goes away.

Also take a look at the uTasker (www.uTasker.com) solution for the NE64 - there is an online demo of the project at http://212.254.22.36
The complete project of free for non-commercial use, inclduing an NE64 simulator. By setting a compiler switch the project can be compiled also for the M5223X (the NE64's big brother!!)

Regards

Mark Butcher
www.mjbc.ch / www.uTasker.com

[nerdboy]

Thanks again for your usual quick response Mark.

We don't use AUTO_NEG because when it is enabled, like you pointed out, the NE64 can't even communicate through a wired router/switch.

I tried running the NE64 at 10Mbps, with half duplex, and with hardware flow control, but no combination of these was successful.

When the NE64 connects to the WiFi bridge, the (hardware-controlled) LEDs immediately indicate full duplex 100Mbps operation. Less than a second thereafter, the LNK LED comes on. At this point, the bridge still seems to operate correctly (judging by its LEDs). Only when the NE64 sends the first packet does the WiFi bridge freeze up. The NE64 will continue trying to send packets regardless...

Any more thoughts? Thanks for the uTasker reference. For our application, we should be able to manage without an OS, but we'll keep it in mind since OpenTCP is less than perfect.

Jeff

[nerdboy]

This problem is still unresolved. Here's an interesting phenomenon that I've discovered:

- Connect a different network device to the WiFi bridge and have it establish contact succesfully.
- Unplug that device from the WiFi bridge
- Configure the NE64 to use the same MAC address as the previous device
- Plug the NE64 into the WiFi bridge

Using this sequence, the NE64 can transmit packets via the WiFi bridge.

So, obviously, there's some initialisation sequence that the NE64 and WiFi bridge do not successfully complete. D-Link (makers of the WiFi bridge) haven't been particularly helpful at explaining what the WiFi bridge does differently than, say, a wired router (which the NE64 CAN communicate with).

Does this give anyone any more ideas of what might be wrong???

Thanks,

Jeff

[nerdboy]

Okay, we've stumbled across one less than ideal solution:

1) Put the NE64 in promiscuous mode (so that it accepts all packets regardless of address)
2) Power up the NE64 and the WiFi bridge (connected together)
3) Wait a bit, and then hard reset the NE64 once or twice

The NE64 will then send UDP packets to a PC via the WiFi bridge (this is roughly our target application). It is possible to switch the NE64 back to unicast mode after the initial connection with the WiFi bridge.

I don't see how promiscuous mode helps, since in Ethereal I don't detect any packets coming from the WiFi bridge on initialisation. If anyone can enlighten me I'd love to understand what's going on!!! :?

Jeff