AM2432: Ethernet IP stack problem with 2. interface

Hi Michael,

Please correct me if I have misunderstood: is CONetItf::InitLwipInterfaces() being called periodically within the same task as the main EtherNet/IP task (where EI_API_ADP_run() is also called)?

Could you provide more context on why InitLwipInterfaces needs to be called periodically? It appears to be an initialization function, so I would expect it to be called only once. Would it be possible to trigger it based on a connection‑status event or interrupt (e.g., when the USB connection is established or dropped) rather than polling it on a fixed interval? I realize I may not have the full picture, so I would like to better understand the use case before drawing any conclusions.

Best regards,
Pourya

Hello Poury, the function InitLwipInterfaces will be called only one time after the for loop. In the for loop the function EI_API_ADP_run is called, bit the initialization of the 2. interface is called after this loop (only once).

Best regards

Michael

Hi Michael,

Thank you for confirming that InitLwipInterfaces is called only once. However, your explanation does not fully address my earlier question: why is this function called in this manner rather than being triggered by an event?

That said, this is speculation on my part. Could you please provide more details about your implementation so that I can offer a more concrete analysis and help resolve the issue properly?

Best regards,
Pourya

Hello Pourya,

The function is called after approximately two seconds because we determined through trial and error when the addition of the second interface actually works; unfortunately, we could not find a specific event for this. There is also the option of querying the module status (modstatus = 3). The module status reaches the "Device operational" state after a very short time, but this duration is insufficient to successfully initialize the second interface.

The following function describes the addition of the 2. interface. It will be use standard functions.

The functions GetIPAdress etc. are user defined and gives in the case of USB 192.168.37.5 back.

The EthernetIP Stack is initialized with  192.168.39.5

void CONetItf::Register(CONetItf* itf) // this function behind InitLwipInterfaces

{

    uint8_t macLen = NETIF_MAX_HWADDR_LEN;

    uint8_t* macAdr = NULL;

    macAdr =   GetMacAddress(macLen);

    EXCEPTION(macLen > NETIF_MAX_HWADDR_LEN, return);

    memcpy(  _netitf.hwaddr,macAdr,macLen);

    uint32_t ipaddr =   GetIP_Address();

    uint32_t netmask =   GetNetMask();

    uint32_t gw =   GetGateway();

      _netitf.hwaddr_len = macLen;

    // store instance pointer in net interface

    // to have faster access in static functions

      _netitf.state = itf;

    if(sys_sem_valid(&InitSemaphore)==0)

    {

      // Create semaphore for inCB     */

      sys_sem_new(&InitSemaphore, 0);

    }

    LOCK_TCPIP_CORE();

    EXCEPTION(netif_add(& _netitf,

        (const ip4_addr_t*)&ipaddr,

        (const ip4_addr_t*)&netmask,

        (const ip4_addr_t*)&gw,

        itf,

        (netif_init_fn) _initCB,

        (netif_input_fn)tcpip_input

    )==NULL, return);

    UNLOCK_TCPIP_CORE();

    sys_sem_wait(&InitSemaphore);

    LOCK_TCPIP_CORE();

    netif_set_default(&_netitf);

    netif_set_status_callback(&_netitf, _statusCB);

    netif_set_link_callback(&_netitf, _linkCB);

    UNLOCK_TCPIP_CORE();

}

One of our problems is, that the ListIdentity service sends back the wrong IP Address (192.168.37.5 instead of 192.168.39.5).

Can you try to reproduce the problem with the EthernetIP example?

Best regards

Michael

Hi Michael,

I believe the root cause of the List‑Identity service returning the wrong IP address is the call to netif_set_default(&_netitf) inside CONetItf::Register. This replaces the EtherNet/IP network interface as the default LwIP interface with your secondary USB‑to‑Ethernet interface, which is likely not the intended behavior. I would recommend removing that call.

The exact "appropriate condition" will depend on your use case—for example, it could be when the EtherNet/IP interface receives a valid IP address, or when the EtherNet/IP netif is first added.

Here is a brief code snippet to illustrate the idea:

// global variable declration
NETIF_DECLARE_EXT_CALLBACK(app_netifEvent_holder)
...

// register your callback
netif_add_ext_callback(&app_netifEvent_holder, app_netif_event_callback);
...

// implement your callaback
void app_netif_event_callback(struct netif* netif, netif_nsc_reason_t reason, const netif_ext_callback_args_t* args)
{
    // Early exit if not the event we care about
    if (!(reason & (LWIP_NSC_IPV4_ADDRESS_CHANGED | LWIP_NSC_IPV4_ADDR_VALID)))
    {
        return;
    }

    // Validate input parameters
    if (NULL == netif)
    {
        return;
    }

    // check if the netif is for the EtherNet/IP and not your USB<->Ethernet interface
    if(netif != &_netitf)
    {
	  //your initialization logic goes here
    }

}

Best regards,
Pourya

Hi Pourya,
Thanks for the tip. In principle, the callback function works, but the Ethernet cable must be plugged in for it to do so; if there is no link, the callback isn't triggered. However, the USB interface should definitely be initialized even if no Ethernet link is present.
When the cable is plugged in, it behaves as before.
If the function `netif_set_default(&itf->_netitf)` is not called, a USB connection cannot be established. If it is called, things go back to how they were before. Unfortunately, I haven't been able to find a solution for this yet.
Best regards,
Michael

Hi Michael,

for initialization problem you could use a combination of a timeout callback and the link-up event from the EIP to initialize your interface, whichever happened first, I know it is not the best practice, but as long as we don't know the root cause we can fix it on symptom level.
Regarding calling 'netif_set_default':

1) Can you confirm, if you do not call netif_set_default, the packets are received for your interface (In your TCP/IP receive callback)?

2) If step 1 works, it means when you want to send the packet on the interface, the LwIP uses ip_route to pick the "correct" netif for outgoing trafic, if subnet of the Tx packet does not match with your USB<->Ethernet Interface, then the packet is sent via netif_default, which suggests to me that there is a mismatch in your interface netmask.
The better way would be to bypass ip_route and send your packets explicitly through your desired netif (USB<->Ethernet), for example using udp_sendto_if, tcp_bind_netif and other similar APIs.

Best regards,
Pourya