This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RM57L843: lwip 1.4.1 and the hdkif.c port

Part Number: RM57L843
Other Parts Discussed in Thread: HALCOGEN

We have a product where we use lwip 1.4.1, the implementation is based on the lwip demo project. We do not use EMAC interrupts for receiveing and transmitting data. All EMAC communication are polled, and all stack usage all happens in the same context (our main loop). We also do not run any os on the target.

We have a use case which produces an error in the stack. Now this problem might not be the stack or the hdkif port, but we are trying to find the culprit.

The good use case, is a test that will run "forever" without any problems. It consist of programs that each send a small UDP packet (UDP payload data of appr. 8 bytes) to our target, and the target answers with a larger packet (UDP payload of up to 512 bytes). This continues forever.
The bad use case, happens when we change one of the programs to send larger udp packets to the target, e.g. up to 480 bytes UDP data. The target will now some times drop a packet, due to the problem described below.

Here is a part of the receiving ( hdkif_rx_inthandler() code from hdkif.c.

      /* Adjust the link statistics */
      LINK_STATS_INC(link.recv);

      /* Process the packet */
      if(ethernet_input((struct pbuf *)q, netif) != ERR_OK) {
        /* Adjust the link statistics */
        LINK_STATS_INC(link.memerr);
        LINK_STATS_INC(link.drop);
      }

We have insertet som debug code above which makes a copy of the pbuf structure (q) and is copying all data from q for debugging before calling ethernet_input.
We use pbuf_copy_partial() to copy the data, it returns that the pbuf chain contains 60 bytes of data. But for some odd reason, these data are spread over 2 pbufs in the chain.
It seems the lwip stack assumes all stack headers, in our case ETH+IP+UDP, can fit in the first pbuf. But since the incoming data in this case is spread over 2 pbufs, all headers will not fit in the first pbuf. In our setup pbufs (memp_malloc) should all be of size 256 bytes, so this is quite weird this is happening.
I have included an image of the CCS watch data and our lwip opts file etc.
How can it happen that the pbuf suddenly only contain a small amount of data in the first pbuf?
Best regards,
Mads
 s