Honored ContributorThe data I actually sent to the board is :
0000 ff ff ff ff ff ff 00 1d 7d 75 c4 24 08 06 00 01 ........}u.$.... 0010 08 00 06 04 00 01 00 1d 7d 75 c4 24 c0 a8 01 07 ........}u.$.... 0020 00 00 00 00 00 00 c0 a8 01 64 .........d but as i observed from signaltap, what ff_rx_data received is "0000fdff ffffffff ffffffff ffff0f00 d01dd17d 577547c4 4c248208 60060000 10018008 ......" And ff_rx_mod is 00. ff is 32 bit width.
Honored Contributorhi Dai,
I am actually using this thing to sniff packet, but I didn't notice there is a statistics funtion. Thanks. I've checked the statistics, now it seems all packets the board has sent out were reported as receive error & CRC/FCS error by the network card driver. Now I'm trying to figure out what causes this, if I've any progress, i'll let you know.Honored ContributorYou could have a look at the MII signals to see what is sent by the TSE core to the PHY. Did you remember to add the two 0 bytes before the header, if the 32-bit alignment option is still active? Did you try packets of different lengths? (especially one big enough so that the TSE doesn't add padding)
Honored ContributorHi Dai,
Check the MII signals, you mean tx_en and txd[3:0] PHY signals? I've checked the tx_en and txd[3:0], all correct, identical to the data I've wrote to the ff. (as the signaltap snapshots I've posted early). I found that one old copy of my project could randomly sent out data to PC. By random I means PC was not receiving packet every second as expected, I've to wait several seconds to several minutes for the PC to receive one packet. I checked the code, and compared with the current project files. The only difference is that I've added a 32bit custom CRC data to the and of the packet, I didn't notice that I've configured TSE to add CRC. And the CRC I've added is also incorrect, so it's just a meaningless 4byte random data. I tried to remove the CRC, and filled it up with a constant 4byte data. The PC never receive any packet again. I am pretty sure it's because the random data of the packet makes the old project file works. Then I added 3bytes of tickcount data to the end of the packet, it turned out to be interesting. The 3bytes of tickcount data goes in this pattern, 0,1,2 / 3,4,5 / 6,7,8/ 9,a,b / c,d,e / f, 10, 11/ ... And the following dump data is what PC received. As you can see, when the counter goes to "38,39,3a" / "5c,5d,5e" / "94,95,96" / "f0,f1,f2", PC received the packet. packet1: 0000 ff ff ff ff ff ff ee 11 22 33 44 50 08 06 00 01 ........ "3DP.... 0010 08 00 06 04 00 01 ee 11 22 33 44 50 c0 a8 01 0a ........ "3DP.... 0020 00 00 00 00 00 00 c0 a8 01 6c 38 39 3a 00 00 00 ........ .l89:... 0030 00 00 00 00 00 00 00 00 00 00 00 00 ........ .... packet2: 0000 ff ff ff ff ff ff ee 11 22 33 44 50 08 06 00 01 ........ "3DP.... 0010 08 00 06 04 00 01 ee 11 22 33 44 50 c0 a8 01 0a ........ "3DP.... 0020 00 00 00 00 00 00 c0 a8 01 6c 5c 5d 5e 00 00 00 ........ .l\]^... 0030 00 00 00 00 00 00 00 00 00 00 00 00 ........ .... packet3: 0000 ff ff ff ff ff ff ee 11 22 33 44 50 08 06 00 01 ........ "3DP.... 0010 08 00 06 04 00 01 ee 11 22 33 44 50 c0 a8 01 0a ........ "3DP.... 0020 00 00 00 00 00 00 c0 a8 01 6c 94 95 96 00 00 00 ........ .l...... 0030 00 00 00 00 00 00 00 00 00 00 00 00 ........ .... packet3: 0000 ff ff ff ff ff ff ee 11 22 33 44 50 08 06 00 01 ........ "3DP.... 0010 08 00 06 04 00 01 ee 11 22 33 44 50 c0 a8 01 0a ........ "3DP.... 0020 00 00 00 00 00 00 c0 a8 01 6c f0 f1 f2 00 00 00 ........ .l...... 0030 00 00 00 00 00 00 00 00 00 00 00 00 ........ .... packet4: 0000 ff ff ff ff ff ff ee 11 22 33 44 50 08 06 00 01 ........ "3DP.... 0010 08 00 06 04 00 01 ee 11 22 33 44 50 c0 a8 01 0a ........ "3DP.... 0020 00 00 00 00 00 00 c0 a8 01 6c 38 39 3a 00 00 00 ........ .l89:... 0030 00 00 00 00 00 00 00 00 00 00 00 00 ........ .... packet5: 0000 ff ff ff ff ff ff ee 11 22 33 44 50 08 06 00 01 ........ "3DP.... 0010 08 00 06 04 00 01 ee 11 22 33 44 50 c0 a8 01 0a ........ "3DP.... 0020 00 00 00 00 00 00 c0 a8 01 6c 5c 5d 5e 00 00 00 ........ .l\]^... 0030 00 00 00 00 00 00 00 00 00 00 00 00 ........ .... packet6: 0000 ff ff ff ff ff ff ee 11 22 33 44 50 08 06 00 01 ........ "3DP.... 0010 08 00 06 04 00 01 ee 11 22 33 44 50 c0 a8 01 0a ........ "3DP.... 0020 00 00 00 00 00 00 c0 a8 01 6c 94 95 96 00 00 00 ........ .l...... 0030 00 00 00 00 00 00 00 00 00 00 00 00 ........ .... packet7: 0000 ff ff ff ff ff ff ee 11 22 33 44 50 08 06 00 01 ........ "3DP.... 0010 08 00 06 04 00 01 ee 11 22 33 44 50 c0 a8 01 0a ........ "3DP.... 0020 00 00 00 00 00 00 c0 a8 01 6c f0 f1 f2 00 00 00 ........ .l...... 0030 00 00 00 00 00 00 00 00 00 00 00 00 ........ .... repeat ...... And soon I replaced the 3 bytes of tickcount data with constant data "38 39 3a", now PC receives data every second. I guess even if I repaced the 3 bytes of tickcount data to 2 bytes or 1 byte tickcount data. I would still found some specific value are working, and the others won't. Weird isn't it?Honored ContributorCorrect me if I'm wrong, but it seems that the packets you actually receive are those with a CRC of 00 00 00 00.
It seems that there is something wrong with the CRC generation. Except if the CRC is romeved by Wireshark or the network driver?Honored Contributoryes, I guess CRC is removed by network driver, or maybe by the PHY of the network card. I always want to catch the CRC from PC, but the dumped data is only 60 Bytes, the 4 bytes of CRC is removed. those zeroes are paddings.
Honored ContributorIn case it's the problem of the TSE CRC generation. I added padding & calculated CRC by myself, and the problem still the same.
Honored ContributorHi
Has there been any resolution to this problem? I'm experiencing the exact same issues. I can tx data, signal tap shows correct data going into ff_rx_data, and the tx LED on the dev board blinks in concert with the LED on the network port of the receiving com. The Wireshark stat details show a increase in dropped packets due to CRC/FCS error everytime I send a packet over. Anyone found a solution to this?Honored Contributor
