Hi.
I've already reported the bug, just posting it here to give it possibly more exposure.
I started out with a bug against the original Freematics firmware, bisected to discover an impossibly minor change, then discovered it was the espressif32 platform in PIO that was causing the issue. To rule out a PIO-specific issue, I've also tried Arduino IDE and had the same problem. This is my last stop, basically.
Please have a look and let me know if you need more information.
Regards,
Andrea.
same source, different core -> webserver hangs
Re: same source, different core -> webserver hangs
This is still happening with the latest core and the bug has not even been assigned.
Once more: do you need more information?
Once more: do you need more information?
Re: same source, different core -> webserver hangs
Hi Andrea,
Sorry noone replied to the original thread and bug report and thanks for being patient about the update.
I think the reason the bug on arduino-esp32 has had no response is for two reasons:
- It's not clear the bug is in arduino-esp32 and not the Freematics firmware.
- The bug report says the Freematics firmware hangs, but running the Freematics firmware requires special hardware which noone on the arduino-esp32 team is likely to have. Digging into the "hang" to find more detail is therefore not something that can be done from the arduino-esp32 end.
(I did see in the original bug report that the code works in an older Arduino-ESP32 release and stopped working in a recent one. This could indicate the bug is in the Arduino framework, but it also could indicate something else - a bug in the Freematics firmware which had no noticeable effect in the old framework now triggers a hang because of timing, or memory layout, or some other minor behavioural change.)
To create an actionable bug report for Arduino-ESP32, you could try to provide some additional information about which APIs are called in the Arduino-ESP32 framework and where exactly the code is hanging in the firmware - what tasks are running, what these tasks are doing at the time it hangs, etc. This will probably require adding debug logs to the Freematics firmware to pinpoint the details. The best possible thing would be a stripped down test case sketch which can run on a generic ESP32 development board, and some steps to reproduce the hang in this sketch.
Angus
Sorry noone replied to the original thread and bug report and thanks for being patient about the update.
I think the reason the bug on arduino-esp32 has had no response is for two reasons:
- It's not clear the bug is in arduino-esp32 and not the Freematics firmware.
- The bug report says the Freematics firmware hangs, but running the Freematics firmware requires special hardware which noone on the arduino-esp32 team is likely to have. Digging into the "hang" to find more detail is therefore not something that can be done from the arduino-esp32 end.
(I did see in the original bug report that the code works in an older Arduino-ESP32 release and stopped working in a recent one. This could indicate the bug is in the Arduino framework, but it also could indicate something else - a bug in the Freematics firmware which had no noticeable effect in the old framework now triggers a hang because of timing, or memory layout, or some other minor behavioural change.)
To create an actionable bug report for Arduino-ESP32, you could try to provide some additional information about which APIs are called in the Arduino-ESP32 framework and where exactly the code is hanging in the firmware - what tasks are running, what these tasks are doing at the time it hangs, etc. This will probably require adding debug logs to the Freematics firmware to pinpoint the details. The best possible thing would be a stripped down test case sketch which can run on a generic ESP32 development board, and some steps to reproduce the hang in this sketch.
Angus
Re: same source, different core -> webserver hangs
Hi, Angus.
First off, thanks for your reply and your time.
Could someone be assigned to that bug anyway, even if they don't have the HW? It kind of defeats the purpose of a bug tracking system to have to use a forum to draw attention to a report. I'll try to create a test case that runs on the devkit and shows the same issue, then update the report.
From your reply, I see I have to clarify one important point: it's not a "hang" of the chip itself, it's the webserver that stalls with newer Arduino cores and worked fine with older ones. I could telnet into port 80 and, for example, run "GET /api/info HTTP/1.0" just fine, while now the TCP connection just stays up but no reply comes back, the chip itself is very much alive and logging on USB just fine.
Regards,
Andrea
First off, thanks for your reply and your time.
Could someone be assigned to that bug anyway, even if they don't have the HW? It kind of defeats the purpose of a bug tracking system to have to use a forum to draw attention to a report. I'll try to create a test case that runs on the devkit and shows the same issue, then update the report.
From your reply, I see I have to clarify one important point: it's not a "hang" of the chip itself, it's the webserver that stalls with newer Arduino cores and worked fine with older ones. I could telnet into port 80 and, for example, run "GET /api/info HTTP/1.0" just fine, while now the TCP connection just stays up but no reply comes back, the chip itself is very much alive and logging on USB just fine.
Regards,
Andrea
Who is online
Users browsing this forum: No registered users and 22 guests