search

MEGA65 / mega65-core

MEGA65 FPGA core
Other
237 stars 84 forks source link

Ethernet TX not working on some boards and core revisions #758

Closed ki-bo closed 4 months ago

ki-bo commented 6 months ago

Test Environment (required) You can use MEGA65INFO to retrieve this.

Describe the bug With the two mentioned core development builds mentioned above, my R3a board stopped sending the IPv6 TX beacons (which you can activate by hitting SHIFT+POUND). Sometimes, I still could see some of them in Wireshark, but in general this was broken. It turned out that TX functionality regressed in general. Some users with R3a still were able to use the Ethernet functionality with not issues using the same core, but I got several reports from other users seeing the same issue as I had.

To Reproduce Steps to reproduce the behavior:

  1. Power-up
  2. Hit SHIFT+POUND
  3. No IPv6 Beacon broadcast is visible on the network (use Wireshark to verify)

Expected behavior The IPv6 beacon should be sent properly once every second.

Additional context It seems this is related to the TX phase setting in the core. Default is '00', although the Ethernet tools and also the WeeIP stack software set this to '01' on initialisation anyway. Obviously, with many core builds in the past, both settings seemed to work fine. But now we start seeing that phase setting '00' is not working reliably all the time.

All users that had reported the issue to me also reported back that setting the TX phase manually to '01' fixes the problem (I can observe the same here). You can do that by doing POKE $D6E5,$36.

We should change the default of TX phase to setting '01' which was proven to work very reliably for everyone during the last year when we were developing the Ethernet tools.

lydon42 commented 6 months ago

As I remember from the conversations this means this should be fixed? So I set it to staged and leave it open for batch testing.

ki-bo commented 6 months ago

As I remember from the conversations this means this should be fixed? So I set it to staged and leave it open for batch testing.

Yes, I believe it should already be fixed in development branch. However, as it only happened randomly for some builds, it will be harder to really do a test. We rather need to see whether it will happen again.

On the other hand, if the error showed, setting the phase to 01 always fixed it for whoever I was in contact with. So, I am quite confident this fix will do alright.