Link RCM2250 and RCM3309 via ethernet without a hub/switch

I have a project where I need to use the ethernet port to link two systems. One system is based on an RCM2250, the other an RCM3309.
The target environment has no network and using a hub/switch is undesirable.
When I connect two RCM3309 systems together directly (one ethernet cable directly from one system to the other), the link appears to come up.
When I connect two RCM2250 systems together directly, the link also appears to come up.
However, when I connect an RCM2250 and RCM3309 system together directly, the link fails to come up (as indicated by the LEDs alongside the ethernet jacks on both modules). If I connect them via a hub, the link comes up fine.

Can anyone shed any light on what is going wrong with the direct RCM2250-RCM3309 ethernet link?
I’m guessing it might be a problem with link speed negotiation, but I can’t see any way to either turn on/off auto-negotiation or force the link speed.

This could be due to a bug in ASIX.LIB that was released in “patch2” for Dynamic C 9.62.

I’ve corrected the bug with this commit on GitHub: https://github.com/digidotcom/DCRabbit_9/commit/896b77064309db57ac85ff5fc73a44df7f7b5254

You can apply that change manually, or download the latest ASIX.LIB from GitHub and see if that resolves the problem.

Tom, thanks for the fix. I’ll give that a try in the next couple of days and let you know if that resolves the issue. In the meantime, I’ve been using DC 9.62 with Patch 2 files but the ASIX.LIB from Patch 1. That combination seems to result in reliable link establishment. However, I’m concerned that there is an issue waiting to catch me out in Patch 1 ASIX.LIB since there was some fix attempted in Patch 2. Assuming you are familiar with the Base, Patch 1, Patch 2 and Master versions of the file, can you confirm what that issue was and I can then judge whether I need to switch to using your latest (Master) version before I ship any product (which will involve me restarting my validation test program).

My update essentially reverts the 1-line change from patch2 (i.e., goes back to patch1) and then changes the line that patch2 was intended to fix. If patch1 is working for you, the version I posted is a minor change unrelated to link detection/recovery, but to when “overflow” and “retransmit” flags are set.

Thanks Tom. In that case, I’ll continue with Patch 1 version of ASIX.LIB and update to your new version in a future product release. I will however still run a test with your new version as soon as I can and let you know the result.

Tom, I ran the test today with your new ASIX.LIB file and I can confirm that it resolves the connectivity issue I reported in my original post.
We’ll incorporate this into our DC 9.62 patches so that all future product builds have this patch.