that’s great! This new firmware is meant to fix the SSL issues.
Hope you can keep running your demo
Unfortunately I was happy too early. Stopping of uploads seems to occure now much less often but very rarely my App still stops uploading (all subsequent push request return with error code -1) while the loop is still running.
Does it work endlessly on your side with firmware v2.2.1?
Hi @RoSchmi,
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
Thanks, I’ll try, actually 5 ms delay.
BtW: Is there a way to reset the MCU -> RTL8720 connection without rebooting the complete board. So one could start a retry of the ssl transmission and would not loose data in ram.
Hi @RoSchmi,
Please add the following codes where you need to restart the MCU -> RTL8720 connection.
pinMode(RTL8720D_CHIP_PU, OUTPUT);
digitalWrite(RTL8720D_CHIP_PU, LOW);
delay(500);
digitalWrite(RTL8720D_CHIP_PU, HIGH);
delay(500);
Best Regards,
Lakshantha
1 Like
Thanks @lakshan . Unfortunately this code alone didn’t work to recover the connection. Probably it would also be needed to reinitialize the serial port of the SAMD51 MCU.
I think it would be too difficult to find out how this could be done.
Best Regards
RoSchmi
Hi @RoSchmi,
You need to initialize the Wi-Fi libraries again after the codes that I have mentioned above.
Best Regards,
Lakshantha
Thanks @lakshan, I’m not sure which code you mean with:
However, before trying this I would like to rule out that there is a memory leak causing the issue.
Do you have some routines which you use on the SAMD51 to test for memory leaks?
@RoSchmi,
I mean these codes.
pinMode(RTL8720D_CHIP_PU, OUTPUT);
digitalWrite(RTL8720D_CHIP_PU, LOW);
delay(500);
digitalWrite(RTL8720D_CHIP_PU, HIGH);
delay(500);
You need to reinitialize the Wi-Fi libraries after the above codes.
To be clear:
- Include the above codes inside your demo, where you need to restart the MCU -> RTL8720 connection.
- Reinitialize the Wi-Fi libraries
Will get back to you if there is any routine to use on the SAMD51 to test for memory leaks.
1 Like
I think, that I have already found some code;
Edit: The code I posted here before didn’t work for me as expected.
Now I’m using this code in my loop to check if there is a memory leak:
(depends on rpcWiFi library)
Edit2: Using pvPortMalloc() is not correct, malloc() has to be used, code is corrected
// Keep track of tries to insert and check for memory leak
insertCounterAnalogTable++;
uint32_t * ptr_one = (uint32_t *)malloc(100);
free(ptr_one);
if (insertCounterAnalogTable == 1)
{
referenceHeapAddr = (uint32_t)ptr_one;
}
lostLeakageBytes = (uint32_t)ptr_one - referenceHeapAddr;
char buf[25] {0};
sprintf(buf, "Allocating at: %10X", (unsigned int)ptr_one);
Serial.println(buf);
sprintf(buf, " Lost %i", lostLeakageBytes);
Serial.println(buf);
Result: There seems to be no memory leak 
that’s great. Thanks for sharing!
Hi @lakshan,
I made tests with 5ms and 6ms delay. Didn’t solve the issue.
In my application it is not needed to store data in Ram permanently, so I can use the watchdog or reboot after a failed upload. With these measures I can do my uploads permanently. For other applications I will have to wait on your team to solve the problem.
Best Regards
RoSchmi
Hi @RoSchmi,
Could you test with a higher delay such as 10ms or 20ms?
Great to hear that you have found a workaround for your application!
Can I know what other applications are you referring to?
Best Regards,
Lakshantha
Hi @lakshan, thanks for your interest,
yes, I can test with 10 or 20 ms if needed.
Actually my App is running flawlessly (delay 4 ms) for 9 hours without using the watchdog, that’s a new record !! 
It’s a pity that I have to stop it now to continue programming.
Did you make any changes in the rpcUnified library update of yesterday which could have been a game changer?
I still have no other serious applications. If I had an idea of an internet using App which has the need of keeping data in the Ram I would not start before the platform has proved to run stable over longer periods of time.
Hi @lakshan,
problem still not completely solved. My App very seldom stops to upload even with 20 ms delay. Sometimes several hundred successful uploads but then one upload fails and the drivers seems not to be able to recover from such an anexpected situation. I’ll try @stevedb 's suggestion tomorrow.
Best Regards
RoSchmi
Hi @RoSchmi,
You could try @stevedb 's suggestion as he has mentioned in his previous post and share your findings here. Thank you.
Best Regards,
Lakshantha
Hi, with stevedb 's suggestion with 100us delay as mentioned -> malfunction after 129 successful uploads. The 130. try to upload (post request) returned with error code -1, on the next try to upload the App crashed (loop stopped running).
BtW: You are using a baudrate of 1.843.200. Did you try using a lower baudrate?
Still the same problems. Occasinally my App hangs an requires reset by the watchdog, occasionally https requests fail and the system doesn’t recover from this situation. Is the Seeed team still trying to fix/improve the WiFi associated libraries?
Very similar problem here. MQTT calls, e.g. connect() sometimes never return, they go away and stay away, which hangs my app. Tracing down the code, the failure seems to be in the low-level write() where select() does not return despite the timeout. I can integrate a watchdog function but I don’t feel this should be seen as a long term solution.
I agree. Implementing a bulletproof communication between MCU and WiFi chip isn’t an easy thing. But I hope that we can see soon some activity on the significant libraries.