FreeRTOS & lwip & heavy traffic

was anyone able to get the lwip demo running on the SAM7X in a relatively high traffic environment (~1000 broadcast packets/s)

FreeRTOS & lwip & heavy traffic

Not answering your question really, but may possibly be significant (or not).  Have you checked the MAC address of the SAM7X.  The default in the code is treated as a multicast address by some routers. Try changing the MAC address to something that starts 00.

FreeRTOS & lwip & heavy traffic

What is your symptom?  If you are missing packets then is an errata about to be produced for the SAM7X which may explain this.  FreeRTOS V4.0.0 will have a work around that I can post now if you like. Other than that, check the MAC address being used as already said. Regards.

FreeRTOS & lwip & heavy traffic

actually yeah the sam7x statistics registers show dropped packets because of no room in pbuf (EMAC_RRE register) but I was getting ~2000 counts between my reads of the register. there’s an errata for it? i didn’t find it :( can you post the workaround? thanks

FreeRTOS & lwip & heavy traffic

Thats because it has not been published yet!  The information is very new. void vEMACISR( void ) { ____/* This ISR can cause a context switch, so the first statement must be a ____call to the portENTER_SWITCHING_ISR() macro.  This must be BEFORE any ____variable declarations. */ ____portENTER_SWITCHING_ISR(); ____/* Variable definitions can be made now. */ ____volatile unsigned portLONG ulIntStatus, ulEventStatus; ____portBASE_TYPE xSwitchRequired = pdFALSE; ____extern void vClearEMACTxBuffer( void ); ____/* Find the cause of the interrupt. */ ____ulIntStatus = AT91C_BASE_EMAC->EMAC_ISR; ____ulEventStatus = AT91C_BASE_EMAC->EMAC_RSR; ____if( ( ulIntStatus & AT91C_EMAC_RCOMP ) || ( ulEventStatus & AT91C_EMAC_REC ) ) ____{ ________/* A frame has been received, signal the lwIP task so it can process ________the Rx descriptors. */ ________xSwitchRequired = xSemaphoreGiveFromISR( xSemaphore, pdFALSE ); ________AT91C_BASE_EMAC->EMAC_RSR = AT91C_EMAC_REC; ____} ____ulEventStatus = AT91C_BASE_EMAC->EMAC_TSR; ____if( ( ulIntStatus & AT91C_EMAC_TCOMP ) || ( ulEventStatus & AT91C_EMAC_COMP ) ) ____{ ________/* A frame has been transmitted.  Mark all the buffers used by the ________frame just transmitted as free again. */ ________vClearEMACTxBuffer(); ________AT91C_BASE_EMAC->EMAC_TSR = AT91C_EMAC_COMP; ____} ____/* Clear the interrupt. */ ____AT91C_BASE_AIC->AIC_EOICR = 0; ____/* If a task was woken by either a frame being received then we may need to ____switch to another task. */ ____portEXIT_SWITCHING_ISR( xSwitchRequired ); } If you compare this ISR with that in the download you will note the use of the ulEventStatus variable is new.  This is required as under *very* exceptional circumstances the ISR register may report no events pending when there actually are. Checking the other registers (with the ulEventStatus variable) catches this. Note this may be barking up the wrong tree for your particular problem but worth trying. Also, not that this is my interpretation of how to fix the problem with the limited information I have.  It might be that Atmel provide a better solution in the Errata. Regards.

FreeRTOS & lwip & heavy traffic

sorry I failed to read "about to be produced" part of your post :) will give this a try and post my results. thanks and have nice weekend.

FreeRTOS & lwip & heavy traffic

I’ve got an update on this matter. By default the emac is configured in Promiscuous mode (CAF on) once this flag is removed all went well. What the CAF bit do is copy all valid packets which includes those that are addressed and not addressed to the Sam7x. I would also remove the NBC bit too. i.e. remove the call     /* Enable the copy of data into the buffers, and ignore broadcasts. */     AT91C_BASE_EMAC->EMAC_NCFGR |= ( AT91C_EMAC_CAF | AT91C_EMAC_NBC ); from prvSetupDescriptors() func

FreeRTOS & lwip & heavy traffic

By default == What’s configured by default in the lwip project

FreeRTOS & lwip & heavy traffic

Magic!