[lwip-users] AVR32 uc3a macb driver serious problem

[Darius Babrauskas]

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

 

macb.c
Description: Binary data