IP Instance stops working SSP 1.7.12


In our proprietary board we have two ethernet interfaces (one for the lan and one for the wan). After a random time, it can be minutes or days, the interfaces stops working (mainly the wan that has telnet server). When interfaces crash, they don't even respond to ping.

I tried to debug the problem but unfortunately E2studio crashes after a while. What I have seen is that the IP Helper threads keep working even if they don't respond to the ping.

Now I have also enabled the traceX hoping to understand something. What do you think I should focus on?

Best Regards


  • Hi Paolo,

    Same problem here with SSP 1.7.0. What i have found is that on a very intense traffic network, Ethernet stops to receive packets after a while. Note that my network has a lot of broadcast and multicast packets moving around (don't know why exactly...) it has cyclic peaks of thousands of packets per second.

    (As an additional reference to my network, note that ENC28J60 PHY from other device, also blocks due this intense traffic, but in this case is a known issue with that component)

    First, the problem has arise on a custom board, so I have moved to a PK-S5D9 board in order to see if the problem also happens, and yes it takes litle more time but it blocks at the end.

    So as it happens on both devices (with different PHY's) my conclusion is that there is something on SSP;

    What i've found:

    1 - When stops to reply to ping requests, data still is arriving to ethernet stack, you can see the packets updating memory pool area.

    2 - For an unknown reason, 'packet_type' seems to be corrupted so the new packets are not processed by the stack.

    From 'nx_renesas_synergy.c':1245

    /** Route the incoming packet according to its Ethernet type. */
    #ifdef FEATURE_NX_IPV6
    if (packet_type == NX_ETHERNET_IP || packet_type == NX_ETHERNET_IPV6)
    if (packet_type == NX_ETHERNET_IP)
    _nx_ip_packet_deferred_receive(nx_rec_ptr->ip_ptr, packet_ptr);
    else if (packet_type == NX_ETHERNET_ARP)
    _nx_arp_packet_deferred_receive(nx_rec_ptr->ip_ptr, packet_ptr);
    else if (packet_type == NX_ETHERNET_RARP)
    _nx_rarp_packet_deferred_receive(nx_rec_ptr->ip_ptr, packet_ptr);
    /** Call the callback for unsupported packet type, if defined. */
    if ((NULL != nx_rec_ptr->p_callback_rec) && (NULL != nx_rec_ptr->p_callback_rec->nx_ether_unknown_packet_receive_callback))
    nx_rec_ptr->p_callback_rec->nx_ether_unknown_packet_receive_callback(packet_ptr, packet_type);
    /** If Ethernet header id invalid, release the packet. */
    nx_packet_release(packet_ptr); << ALWAYS GETTING HERE AFTER THE FAILURE
    return ;

    I have seen on the forum, that more people has suffered this issue without get a clear solution.

    As a temporal workaround... is there any way to safely restart the ip stack?

    RENESAS PEOPLE: Note that i suspect that it only happen under a high network traffic environment so probably there is an unknown bug on the stack.



  • Hi Oscar.

    I also have a lot of broadcast and multicast traffic on my network. For the moment doing a dedicated VLAN seems to work without problems. I'll keep you up-to-date.


Reply Children