Ethernet adapter not working in long run

Official Hardware Portenta Family Portenta C33
1

Hey all.
I implemented a http server on C33.
But in a stress test the board doesn't do well.
I take the smallest sample.

#include <EthernetC33.h>

EthernetServer server(7);

void setup() {
  Serial.begin(9600);

  if (Ethernet.begin() == 0) {
    Serial.println("Failed to configure Ethernet using DHCP");
  }
  server.begin();
  Serial.print("server is at ");
  Serial.println(Ethernet.localIP());
}


void loop() {
  EthernetClient client = server.available();
  if (client) {
    char previous_c = 0;
    int sequential_newline = 0;
    char buffer[1024];
    int pos = 0;

    while (client.connected()) {
      if (client.available()) {
        char c = client.read();

        if (previous_c == '\r' && c == '\n')
          sequential_newline++;
        else if (previous_c != '\n' || c != '\r')
          sequential_newline = 0;

        if (sequential_newline == 2)
          break;

        previous_c = c;
        buffer[pos++] = c;
      }
    }
    
    client.write(buffer, pos );

    delay(1);
    // close the connection:
    client.stop();
  }
}

and the python code to call

import socket

server_address = ('192.168.0.103', 7)  # Replace with the desired server address and port

while True:
    tcp_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    tcp_socket.connect(server_address)

    data = b"POST /mode/IDLE HTTP/1.1\r\nHost: 192.168.0.103\r\nUser-Agent: python-requests/2.28.1\r\nAccept-Encoding: gzip, deflate, br\r\nAccept: */*\r\nConnection: keep-alive\r\nContent-Length: 0\r\n\r\n"
    tcp_socket.sendall(data)

    while True:
        response = tcp_socket.recv(1024)

        if not response:
            break

        print(response.decode(), end='')

    tcp_socket.close()

I take a deep look on the source code too. It looks that a problem in lwip function
tcp_output that doesn't clean the recv buffer in some way.
And it's looks that is something low level because the C33 stops to respond to ping too.

Any help?

2

I forgot to add, in lwip functions is called tcp_write to add the buffer and tcp_output to send the buffer, but tcp_write keep returning ERR_MEM.

3

Also, there is no SDCard on the shield.

4

I am having the same trouble. Where is the source code for "tcp_output()"? I would like to fix it, but I can NOT find it. Looks like it is buried in "liblwip.a"...

5

You're right. It is buried in liblwip.a.
Has solution, I connected a w5500 lite and worked with it.

6

I am working with the Renesas Portenta C33 platform, any idea how to get the source code for the file that has that (broken) tcp_output() function? I would like to be able to use both wired and wireless networking -- neither are working. So is it true that there's is no "open source" code for the Renesas "liblwip" library?

7

OK, Eduardo, I modified the C33 libraries and got the wireless semi-working now, but the Ethernet still has major problems. I would like to implement your "w5500 lite" solution. Which module/board (make and part-number) did you get working?

8

Hi all,

I am getting a similar fault when using a UDP socket for periodic transmission of data (1 to 10 Hz). The data is flowing between C33 (sender) and PC (receiver), for some seconds, but after a while (around 140 packets), the ethernet connection gets stuck, and I am not able even to perform ping.
Reading from different sources, it seems a buffer problem from the middleware. I am using a PortentaC33+ Hat carrier for ethernet RJ45 port.
Has anyone solved the problem?
Thanks

9

Sadly, alvaroav, none of the networking on the C33 is fully functional. The wireless interface works better than Ethernet. Both do work OK for short periods of time, but then crash/hang. Many have tried to fix this but have failed thus far.

10

Thanks for your answer!! Then I should move to a different board.
Hopefully this will be solved by Arduino soon, otehrwise the ethernet option for C33 is useless.
Thanks again!

11

Unfortunately, Arduino is not working on fixing this issue, it is a Renesas core library problem. We moved to a different board, having to re-work all of our code, but the ESP32-C6 platform we have now works flawlessly.