Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
15 years ago

Weird Ethernet problem

Premise: I don't know if this weird problem is related to TSE, sgdma or Nios code. Please help me to identify, or better, to solve it.

I'm using Nios II with tse mac and National Semi DP83640 phy. I trasmit and receive Ethernet frames and sometimes tx or rx frames are lost and I can't understand why.

I monitored both the Ethernet link and the TSE-phy signals and I'm testing with a system that immediately loops back the rx frame.

This is what I see:

- the txen signal from the mac is always correctly generated

- the rxen signal (same behavior for crs signal, carrier sense) sometimes is lost

- often, when rxen is missing, I can neither see any frame transmitted on the cable, although sometimes I do.

And now the weirdest part:

The error seems to be almost deterministic if a rx frame arrives just after I have transmitted a frame, say within a few microsec, while it never happens if the rx frame is superimposed to tx or even if it is delayed.

So, if I use a direct loopback I seldom have any error, while the error is systematic if I insert an Ethernet hub, which delays tx/rx frames about 20us

I simplified my tx function in the following way, in order to debug with a single constant data frame, but nothing has changed.


void test_frame(void)
{
   PACKET outpkt;
   int len;
  
    len = 40;
    
   LOCK_NET_RESOURCE(FREEQ_RESID);
   outpkt = pk_alloc(len+20);
   UNLOCK_NET_RESOURCE(FREEQ_RESID);
   if (!outpkt) {
      printf("Error: pk_alloc() failed");
      dtrap();
      return;
    }
   memset(outpkt->nb_buff, 0, len+ETHHDR_SIZE+ETHHDR_BIAS);
/*  
     here I init packet with my constant data
*/
   
   outpkt->nb_plen = ETHHDR_BIAS + len;
    
   if (outpkt->net->pkt_send)   {
      outpkt->nb_prot = outpkt->nb_buff;
      outpkt->net->pkt_send(outpkt);
     }
   else   {
      outpkt->net->raw_send(ecat_net, outpkt->nb_buff, outpkt->nb_plen);
      LOCK_NET_RESOURCE(FREEQ_RESID);
      pk_free(outpkt);
      UNLOCK_NET_RESOURCE(FREEQ_RESID);
   }
        
}

Thank you for any advice

Cris

11 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Cris,

    Well, that's weird. I don't know what to tell you. Maybe it's not the TSE or Ethernet but somehow the OS causing this. Like some timing dependency or deficiency or something. Unfortunately, you can't run Interniche without uC/OS-II (which is why I chose not to use Interniche!). Divorcing them might be possible but I read that this "superloop" mode is hard to get running. I'm thinking if you can just send and receive with UDP or lower level without the OS you can find out where the problem isn't, which might lead you to find where it is.

    You might be pushing the envelope too and that can cause problems the developers don't see (and in all fairness might not expect because you become an "unusual" user). I pushed the limits and rewrote most of the TSE and SGDMA code because the Altera libs couldn't be more inefficient. They work for the "normal" users - but my product would have be canceled at the Ethernet speeds supplied with the Altera and Interniche code. I had to do what I did to get the speeds sufficient to meet the product's goals (which for Gigabit Ethernet were not *that* aggressive).

    Bill