Wio Terminal WebServer fails after a few minutes

Hi,
When I run the HelloServer or the AdvancedWebServer examples the wio terminal just stops executing after 1 - 3 minutes. I can still ping the ip address given to the device but the webserver stops responding and any code I put in loop does not execute.

Enabling debug in rpc_unified_log.h the stall/crash always ends on this log output:

FUNC_EXIT: lwip_accept L#29 Return Code : -1
FUNC_ENTRY: lwip_accept L#24

I’m running Arduino ide V1.8.13
The Seeed Arduino WiFi library is version 1.0.2
I updated the RTL8720 to firmware version v2.1.0
…BTW I tried V2.0.4 but that didn’t work at all for me, but I didn’t spend much time looking into that.

Is this just the current state of the library and firmware?
Am I alone in this observation?
Any advice would be great - I’d really like to get the webserver functionality working reliably.

Many thanks,
Steve

Hi @stevedb

Could you check whether the following libraries are up to date:
Seeed_Arduino_rpcWiFi - v1.0.2
Seeed_Arduino_rpcUnified - v2.1.1
Seeed_Arduino_FS - v2.0.2
Seeed_Arduino_SFUD - v2.0.1

Also make sure to use the Seeed_Arduino_mbedtls in dev branch

Finally, make sure the Wio Terminal SAMD core is updated to v1.8.1

Let me know the result

Best Regards,
Lakshantha

Thanks for the suggestions Lakshantha,
I have checked and my setup is exactly as you describe.
I take it this is working fine for you?
Cheers,
Steve

Hi @stevedb

I have run the webserver related examples with the latest firmware/ libraries and I face the same issues as you.

I will look into it and get back to you with a fix.

Best Regards,
Lakshantha

Thanks for checking. At least I know it’s not my hardware :slight_smile:
I look forward to the fix.
Many thanks,
Steve

Hi @stevedb,

The issue seems to be the delay inside the serial port transmission section of the code. I have increased the delay and updated the Seeed_Arduino_rpcUnified library. You can check the commit below.

I have also tested with the AdvancedWebServer example and it seems to be stable for over an hour.

e66996af29bab0f71cb08ebf4e6c510

Please update the Seeed_Arduino_rpcUnified library and run the demo code again.

Best Regards,
Lakshantha

1 Like

Awesome Lakshantha! After updating rpcUnified I’ve been running for over an hour too.
I’ll leave it running longer but it looks resolved to me.
Many thanks,
Steve

1 Like

Hi @lakshan,
I’ve run a few extended tests on this and observe it still fails after 3 to 10 hours.
The last few lines of lwip logging produces this output; note the strange gap in timestamps like it stopped and recovered. I guess there is some underlying stability issue here.

04:24:23.936 -> FUNC_ENTRY: lwip_accept L#24
04:24:23.969 -> FUNC_EXIT: lwip_accept L#29 Return Code : -1
04:24:23.969 -> FUNC_ENTRY: lwip_accept L#24
04:24:23.969 -> FUNC_EXIT: lwip_accept L#29 Return Code : -1
04:24:23.969 -> FUNC_ENTRY: lwip_accept L#24
05:36:08.334 -> FUNC_EXIT: lwip_accept L#29 Return Code : -1
05:36:08.334 -> FUNC_ENTRY: lwip_accept L#24
06:47:50.382 -> FUNC_EXIT: lwip_accept L#29 Return Code : -1
06:47:50.382 -> FUNC_ENTRY: lwip_accept L#24

I’ve only tried this with the AdvancedWebServer example.

Steve

Hi @stevedb

The RTL firmware got updated today. Please try using this:

I will also test the webserver on my end using the new firmware.

Best Regards,
Lakshantha

Hi @lakshan, I’ve tried with the new firmware.
I still get the same crash after several hours.
Steve

Hi @stevedb,
Could you try changing the delay value here Seeed_Arduino_rpcUnified > src > erpc > erpc_arduino_uart_transport.cpp (line 299) on your end and test it? The delay seems to be the issue. When the delay is too high, it seems to be slow, and when the delay is too low, it seems to be unstable.

Best Regards,
Lakshantha

Hi @lakshan,
I haven’t managed to look into this in detail but thought I would offer a brief update.
I thought I would try and insert a delay for every transmit that hit the uart tx buffer when it was not empty rather than in the underlysingsend function that transmits in bulk.
I’ve has some success with a 100us delay as per below; this change is in addition to removing all delays in underlyingsend.
I’ve only run it for about 48 hours but I have seen no crashes with this change yet.

size_t EUart::write(const uint8_t data)
{
  if (sercom->isDataRegisterEmptyUART() && txBuffer.available() == 0)
  {
    sercom->writeDataUART(data);
  }
  else
  {
	delayMicroseconds(100); // slow things down if the buffer is not available
    // spin lock until a spot opens up in the buffer
    while (txBuffer.isFull()) ...

I’ll try and investigate further.
Cheers,
Steve

2 Likes

Thank you for your suggestions @stevedb

I will try and test from my end as well. Please share your findings as well. Appreciate the efforts!

Best Regards,
Lakshantha

Hi @stevedb,
what are your actual results? Is the webserver now running without crashes or hangs?
Best regards
RoSchmi

Hi @RoSchmi,
I only recently moved my wio terminal from the usb of my laptop to a plugged in power source. It was failing on opening or closing my laptop lid which was messing with my observations - another thing to investigate!
In short I ran it for about 10 days without issue. I don’t have a client connected to it all the time, but I don’t think that made a difference to the mode of failure.
I moved the delay to the first line of EUart::write by the way.
Interestingly after those 10 days my wio terminal seems to not work at all! The screen is blank even after a reset (I had some debug printed on there) and it doesn’t connect to the wifi anymore - I haven’t looked into this yet.
Steve

Oh, that’s sad, thanks for your reply