Re: [lwip-users] change PHY and strange behaviour

[Noam weissman]

Hi,

I found a different patch for ethernetif_input function

void ethernetif_input( void * pvParameters )
{
  struct pbuf *p;
  
  for( ;; )
  {
    if(xSemaphoreTake(Ethernet_xSemaphore,
emacBLOCK_TIME_WAITING_FOR_INPUT) == pdTRUE)
    {
TRY_GET_NEXT_FRAGMENT:
      p = low_level_input( s_pxNetIf );
      if(p != NULL) 
      {
        if(ERR_OK != s_pxNetIf->input(p, s_pxNetIf))
        {
          pbuf_free(p);
          p = NULL;
        }
        else
        {
          xSemaphoreTake(Ethernet_xSemaphore, 0);
          goto TRY_GET_NEXT_FRAGMENT;
        }
      }
    }
  }
}


--------------------------------------------

Also something very important that I found the hard way :-(

ETH IRQ priority should be lower than OS. The reason is that all
FreeRTOS function uses critical section and if the ETH
Priority is higher than the OS it will not disable the ISR.

This is a suggestion, put this in your FreeRTOSConfig.h  file :

/* Cortex-M specific definitions. */
#ifdef __NVIC_PRIO_BITS
        /* __BVIC_PRIO_BITS will be specified when CMSIS is being used.
*/
        #define configPRIO_BITS                 __NVIC_PRIO_BITS
#else
        #define configPRIO_BITS                 4        /* 15 priority
levels */
#endif

/* The lowest interrupt priority that can be used in a call to a "set
priority"
function. */
#define configLIBRARY_LOWEST_INTERRUPT_PRIORITY                 0xF

/* The highest interrupt priority that can be used by any interrupt
service
routine that makes calls to interrupt safe FreeRTOS API functions.  DO
NOT CALL
INTERRUPT SAFE FREERTOS API FUNCTIONS FROM ANY INTERRUPT THAT HAS A
HIGHER
PRIORITY THAN THIS! (higher priorities are lower numeric values. */
#define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY    5

/* Interrupt priorities used by the kernel port layer itself.  These are
generic
to all Cortex-M ports, and do not rely on any particular library
functions. */
#define configKERNEL_INTERRUPT_PRIORITY                 (
configLIBRARY_LOWEST_INTERRUPT_PRIORITY << (8 - configPRIO_BITS) )
/* !!!! configMAX_SYSCALL_INTERRUPT_PRIORITY must not be set to zero
!!!!
See http://www.FreeRTOS.org/RTOS-Cortex-M3-M4.html. */
#define configMAX_SYSCALL_INTERRUPT_PRIORITY    (
configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY << (8 - configPRIO_BITS) )


#define ETH_ISR_PRIO           10
#define SERIAL_ISR_PRIO        6


------------------------------------------------------------------------
-------------------------------------


Inside the initialization code of your ETH ISR set the priority to the
above value, something like this:

  NVIC_PriorityGroupConfig(NVIC_PriorityGroup_4);
   
  /* Configures and enable the Ethernet global interrupt. */
  NVIC_InitStructure.NVIC_IRQChannel = ETH_IRQn;
  NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = ETH_ISR_PRIO;
  NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;
  NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
  NVIC_Init(&NVIC_InitStructure);    



Good luck,
Noam.





-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of
George Ruinelli
Sent: Thursday, June 12, 2014 7:28 PM
To: 'Mailing list for lwIP users'
Subject: Re: [lwip-users] change PHY and strange behaviour

Hi pcu

I am also using the LAN8720 in RMII, together with an STM32F4 and
FreeRTOS.

I also had an issue with lost packages. That was solved by a patch
provided in this list.
Have a look at the thread at
http://lists.gnu.org/archive/html/lwip-users/2013-09/msg00025.html

With this fix lwIP works without any issues.

Hope that helps.

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users

 
 
************************************************************************
************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals &
computer viruses.
************************************************************************
************






************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer 
viruses.
************************************************************************************