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 stop working

Part Number: RM57L843

Hi,

My customer reported an issue using LwIP 1.4.1.
Two RM57L boards are connected with Ethernet and 256bytes of data are sent/received repeatedly.
After a few minutes, it stops working and send callback is never called.

Here are customer's code:
a) recv_callback() is receive callback and it receives 256bytes data.
b) sent_callback() is send callback. After 256bytes are sent by tcpSend256(), sndWl_complete flag is set('1').
c) tcpSend256() is transmit sub-routine. sndWl_complete=1 is checked with 8msec interval and call it.

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
struct tcp_pcb* conn_pcb=NULL;
err_t recv_callback(void *arg, struct tcp_pcb *tpcb,
struct pbuf *p, err_t err) {
struct pbuf *pre_p = p;
LWIP_UNUSED_ARG(err);
/* do not read the packet if we are not in ESTABLISHED state */
if (!p) {
conn_pcb = NULL;
tcp_recv(tpcb, NULL);
tcp_sent(tpcb, NULL);
tcp_err(tpcb, NULL);
tcp_close(tpcb);
return ERR_OK;
}
/* indicate that the packet has been received */
do{
// check if received data is under analysis
if(rcvAnaFlg == 0){
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 

Q1) Is there a related known issue in LwIP 1.4.1?
Q2) Do you have any concerns in customer's test code?

Please let me know if you need further information from customer.

Thanks and regards,
Koichiro Tashiro

  • Hi Koichiro-san,

    I don't know any known issue in LWIP1.4.1. 

    I don't know much about TCP/IP protocol, and no comment to the test code at this moment.

    1. Is the memory containing the buffer descriptors in cacheable space? 

    2. Once in the failing condition, please read the MACSTATUS register and let us know the value

  • Hi QJ,

    1. Is the memory containing the buffer descriptors in cacheable space? 

    The buffer resides in RAM area. Could you tell me how to check the area is cacheable or not?

    2. Once in the failing condition, please read the MACSTATUS register and let us know the value

    MACSTATUS value is 0x8000:0000.

    Thanks and regards,
    Koichiro Tashiro

  • Hi QJ,

    Customer did some internet research and found the issue may be related to below window probe issue.
    https://lists.gnu.org/archive/html/lwip-devel/2017-05/msg00040.html

    To solve this situation, it seems tcp_zero_window_probe() should be called from transmitter side.
    tcp_zero_window_probe() is inside tcp_slowtrm() function in below file line#840.
    \hercules_examples-master\Application\LwIP\v00.04.00\lwip-1.4.1\src\core\tcp.c
    But the program does not reach this code. tcp_slowtrm() is called periodically (500msec interval with RTI).

    BTW, customer experimentally enabled KeepAlive as KeepAlive feature is very similar to “Window Probe”.
    Then the issue did not happen.
    Customer does not want to use KeepAlive as it requires additional operations to recover.
    So he wants to use “Window Probe”.

    Thanks and regards,
    Koichiro Tashiro

  • tcp_zero_window_probe() sends persist timer zero-window probes. tcp_zero_window_probe() is called by tcp_slowtmr().

    I am not familiar to those functions.