My device with avr32uc3a, lwip(1.2), freertos   at two network (named A and B) 
always “hung”.  It have 2 modes. Auto() (100Mbit Full duplex)  and 10Mbit half 
duplex. Both modes will “hung”. 
Device need restart.
At my workplace working OK.
I scanned network A with wireshark and found that at network have more 
broadcast and multicast messages.

So, at work place I test my device with simple test sofware, which send arp 
request to device and sent more broadcast messages. 
In 10Mbit half duplex mode, my device  very fast “hung”. Then with debugger, I 
found that lwip thread stopped(cycled) in  lMACBSend function:
at ....while( !( xTxDescriptors[ uxTxBufferIndex ].U_Status.status & 
AVR32_TRANSMIT_OK ) )

    while( !( xTxDescriptors[ uxTxBufferIndex ].U_Status.status & 
AVR32_TRANSMIT_OK ) )
    {
#ifdef FREERTOS_USED
          // There is no room to write the Tx data to the Tx buffer.
          // Wait a short while, then try again.
      vTaskDelay( BUFFER_WAIT_DELAY );
#else
      __asm__ __volatile__ ("nop");
#endif
    }
With debugger I see, that RLE and COL flags  in  MACB.TSR and  UBR  (used bit 
read)  
flag  (so transmitting  stopped, and  xTxDescriptors[ uxTxBufferIndex 
].U_Status.status  newer change,  – cycled forever )  


So I found this old article with same problem:
https://lists.gnu.org/archive/html/lwip-users/2010-04/msg00038.html


In 10Mbit half duplex mode, avr32 macb driver can’t sent arp response, because 
it receiving broadcast messages in network. Since we get transmission error RLE 
and COL flags.

At 100Mbit full duplex mode with this arp-broadcast test, working ok, because 
Full duplex mode is collision free. Its question for me:
Why in networks A, B hung at 100Mbit Full duplex? 
//////   AVR32 MACB documentation

If transmission stops due to a transmit error, the transmit queue pointer 
resets to point to the
beginning of the transmit queue. Software needs to re-initialize the transmit 
queue after a transmit error.


– there is a transmit error such as too many retries or a transmit under run.

Transmit underrun, occurs either when hresp is not OK (bus error) or the 
transmit data could not be fetched in time or
when buffers are exhausted in mid frame.

If a “used” bit is
read midway through transmission of a multi-buffer frame, this is treated as a 
transmit error.
Transmission stops, tx_er is asserted and the FCS is bad.

//////////////////////////////////////////////////

Since, macb code do not handling  macb errors,  and macb hardware reset  “ 
transmit queue pointer “, but macb not reset self pointers (uxTxBufferIndex , 
and uxNextBufferToClear  )

Currently I make in code Reset Tx descriptors, and testing. In 10Mbit mode now 
working ok. But in 100Mbit mode, I don’t know which error occurs RLE or UND... 
(Full duplex mode is collision free ). 

I attached macb.c file for testing. Please find define 
USE_MAC_TX_DESCRIPTOR_RESET_ON_ERROR   that view changes.  I test macb.c file 
from last atmel framework 3.27. lMACBSend function very similar like my old 
macb.c file.

Currently, with this changed macb.c file and small other  , at network B 
working OK in 100Mbit full duplex mode.  At network A , I cant change firmware, 
but it working ok with other solution, –separating networks with router – 
decrease broadcast, multicast messages . 

Best regards

Darius Babrauskas



Attachment: macb.c
Description: Binary data

_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users

Reply via email to