EthernetWebserver fails with big files (>50kB) on STM32NUCLEO using builtin ethernet

[tothtechnika]

Describe the bug

I use the ethernet library with large files from program memory on Nucleo F767. I tried with Nucleo F207 too. In both cases, I experienced that the server stops after a few (1...4) attempts. (no answer for ping). The smaller F207 board makes the error sooner. I also tried the EthernetWebServer_SSL_STM32 directory, but I am experiencing the same error. The error occurs on Windows and OSX too.

Steps to Reproduce

Sample code:

#define USE_BUILTIN_ETHERNET    true
#include <EthernetWebServer_STM32.h>
EthernetWebServer server(80);
byte macc[6] =  {0x00,0x80,0xE1,0x00,0x00,0x00};
/* this pizza.jpg is 540kB size */
static const unsigned char pizza_jpg[]  = {255,216,255,224,0,16,74,70,  ... ... ... .. 134,181,110,149,29,70,222,162};

void setup(void)
{
    Ethernet.begin(macc);
    server.on("/pizza.jpg", []() {
         server.send_P(200, "image/jpeg", (PGM_P)pizza_jpg, sizeof(pizza_jpg));
     });

   server.onNotFound([]() {
    server.send(404, "text/plain", "Not found file");
  });
  server.begin();
  Serial.println(Ethernet.localIP());
}

void loop(void)
{
  server.handleClient();
}

Expected behavior

The program does not freeze in the browser even after repeated requests for large files

Actual behavior

After 1...4 GET requests in the browser, the program and board freezes (ping is not answered) and the image does not load.

Debug and AT-command log (if applicable)

N/A

Screenshots

Information

Please ensure to specify the following:

• Arduino version is:1.8.13
• Board: STM nucleo-144 (32F207, and 32F767)
• OS: osx Mojave
• dhcp configuration
• mikrotik routerboard - default config.

[khoih-prog]

Thanks for your interest in the library.

I'm sorry I don't have time to recreate the settings / scenario to duplicate your issue. You have to somehow post the full code so that anybody can verify easily, without spending much time.

Can you try your code on ESP32 using ESP32 WebServer or ESP8266 using ESP8266WebServer to see if the issue still exists.

Also try either

1. to use PROGMEM like this

static const unsigned char pizza_jpg[] PROGMEM = {255,216,255,224,0,16,74,70,  ... ... ... .. 134,181,110,149,29,70,222,162};

2. not to use PROGMEM command at all, to see if it's better on STM32.

server.on("/pizza.jpg", []() 
{
  server.send(200, "image/jpeg", pizza_jpg, sizeof(pizza_jpg));
});

I'm closing the issue now, and will reopen whenever you test the recommendation and still having issue, then post the full MRE code or prove this is a bug of the library.

Good Luck,

[tothtechnika]

Unfortunately, your solution doesn't work. Sending a const progmem variable does not work with the server.send() function. The following link allows you to download a small test program. After about 3-4 attempts, the program crashes. This link: testwebserverfault.zip

[khoih-prog]

Try to have a look at ESP32_FSWebServer_DRD example and and use some way to save / load your binary image file from Flash.

It's so terrible to have all jpg file (in txt), in .ino => difficult to load / edit the too-large file.

I'm surprised that you can even compile and run the code, especially for MPU with limited power / memory, etc.

Anyway, try the code with this addition

...

void heartBeatPrint(void)
{
  static int num = 1;

  Serial.print(F("."));

  if (num == 80)
  {
    Serial.println();
    num = 1;
  }
  else if (num++ % 10 == 0)
  {
    Serial.print(F(" "));
  }
}

void check_status()
{
  static unsigned long checkstatus_timeout = 0;

#define STATUS_CHECK_INTERVAL     10000L

  // Send status report every STATUS_REPORT_INTERVAL (60) seconds: we don't need to send updates frequently if there is no status change.
  if ((millis() > checkstatus_timeout) || (checkstatus_timeout == 0))
  {
    heartBeatPrint();
    checkstatus_timeout = millis() + STATUS_CHECK_INTERVAL;
  }
}

void loop(void)
{
  server.handleClient();
  delay(1000);
  check_status();
}

and I could run many Clients many times repeatedly, with Nucleo-144 F767ZI

That's some food for thought, and you're on your own.

I'm sorry I won't spend more time here. You'd better ask for help after you do the test with better ESP32/ESP8266, then verify if your code is working there. If not, ask for help in ESP32/ESP8266 forum.

Good Luck,