FYI: Espressif have (finally) released a test toolchain for our PSRAM issue: https://github.com/espressif/esp-idf/issues/2892 <https://github.com/espressif/esp-idf/issues/2892> Linux <https://dl.espressif.com/dl/xtensa-esp32-elf-linux64-1.22.0-90-g26d9621-5.2.0-psramfix-20190605.tar.gz> Windows <https://dl.espressif.com/dl/xtensa-esp32-elf-win32-1.22.0-90-g26d9621-5.2.0-psramfix-20190605.tar.gz> OSX <https://dl.espressif.com/dl/xtensa-esp32-elf-macos-1.22.0-90-g26d9621-5.2.0-psramfix-20190605.tar.gz> Apparently, we need to include the following flags: CFLAGS+=-mfix-esp32-psram-cache-dupldst CXXFLAGS+=-mfix-esp32-psram-cache-dupldst This is a preliminary test fix only, so not for general release, but worth trying. Regards, Mark
Not worth trying yet. It seems the toolchain libstdc++ hasn't been built with workaround, std::string is still broken. Regards, Michael Am 05.06.19 um 09:19 schrieb Mark Webb-Johnson:
FYI: Espressif have (finally) released a test toolchain for our PSRAM issue:
https://github.com/espressif/esp-idf/issues/2892
Linux <https://dl.espressif.com/dl/xtensa-esp32-elf-linux64-1.22.0-90-g26d9621-5.2.0-psramfix-20190605.tar.gz> Windows <https://dl.espressif.com/dl/xtensa-esp32-elf-win32-1.22.0-90-g26d9621-5.2.0-psramfix-20190605.tar.gz> OSX <https://dl.espressif.com/dl/xtensa-esp32-elf-macos-1.22.0-90-g26d9621-5.2.0-psramfix-20190605.tar.gz>
Apparently, we need to include the following flags:
|CFLAGS+=-mfix-esp32-psram-cache-dupldst CXXFLAGS+=-mfix-esp32-psram-cache-dupldst|
This is a preliminary test fix only, so not for general release, but worth trying.
Regards, Mark
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
It *is* worth trying, Espressif just forgot to mention a necessary build config change. Details: https://github.com/espressif/esp-idf/issues/2892#issuecomment-499184318 I've created a test branch for this: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commits/spi... I'm now running the new version on both my modules, and they seem to be very stable up to now. Not a single websocket data corruption yet. I'll publish the build to my "edge" users now. Regards, Michael Am 05.06.19 um 19:01 schrieb Michael Balzer:
Not worth trying yet.
It seems the toolchain libstdc++ hasn't been built with workaround, std::string is still broken.
Regards, Michael
Am 05.06.19 um 09:19 schrieb Mark Webb-Johnson:
FYI: Espressif have (finally) released a test toolchain for our PSRAM issue:
https://github.com/espressif/esp-idf/issues/2892
Linux <https://dl.espressif.com/dl/xtensa-esp32-elf-linux64-1.22.0-90-g26d9621-5.2.0-psramfix-20190605.tar.gz> Windows <https://dl.espressif.com/dl/xtensa-esp32-elf-win32-1.22.0-90-g26d9621-5.2.0-psramfix-20190605.tar.gz> OSX <https://dl.espressif.com/dl/xtensa-esp32-elf-macos-1.22.0-90-g26d9621-5.2.0-psramfix-20190605.tar.gz>
Apparently, we need to include the following flags:
|CFLAGS+=-mfix-esp32-psram-cache-dupldst CXXFLAGS+=-mfix-esp32-psram-cache-dupldst|
This is a preliminary test fix only, so not for general release, but worth trying.
Regards, Mark
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
On 2019-06-05 09:57, Michael Balzer wrote:
It *is* worth trying, Espressif just forgot to mention a necessary build config change.
Details: https://github.com/espressif/esp-idf/issues/2892#issuecomment-499184318
I've created a test branch for this: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commits/spi...
For the git challenged (e.g. me) here's what seemed to work to clone a working copy: git clone -b spiram-fix-test --single-branch https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3.git Open-Vehicle-Monitoring-System-3-spiram-fix-test However I don't think this is useful to me without the newer toolchain? I tried updating my freebsd port: 5,6c5,6 < DISTVERSION= 1.22.0.g20171219 < PORTREVISION= 3 --- > DISTVERSION= 1.22.0.g20190605 > #PORTREVISION= 3 63c63 < TAGNAME= 1.22.0-80-g6c4433a5 --- > TAGNAME= 1.22.0-90-g26d9621 but espressif/crosstool-NG doesn't have that tag and actually it isn't published anywhere yet? Craig
Yes, you need the new toolchain. It's been published here: https://github.com/espressif/esp-idf/issues/2892#issuecomment-498965365 No FreeBSD port yet, I'm afraid. Regards, Michael Am 08.06.19 um 19:04 schrieb Craig Leres:
On 2019-06-05 09:57, Michael Balzer wrote:
It *is* worth trying, Espressif just forgot to mention a necessary build config change.
Details: https://github.com/espressif/esp-idf/issues/2892#issuecomment-499184318
I've created a test branch for this: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commits/spi...
For the git challenged (e.g. me) here's what seemed to work to clone a working copy:
git clone -b spiram-fix-test --single-branch https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3.git Open-Vehicle-Monitoring-System-3-spiram-fix-test
However I don't think this is useful to me without the newer toolchain? I tried updating my freebsd port:
5,6c5,6 < DISTVERSION= 1.22.0.g20171219 < PORTREVISION= 3 --- > DISTVERSION= 1.22.0.g20190605 > #PORTREVISION= 3 63c63 < TAGNAME= 1.22.0-80-g6c4433a5 --- > TAGNAME= 1.22.0-90-g26d9621
but espressif/crosstool-NG doesn't have that tag and actually it isn't published anywhere yet?
Craig
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
On 2019-06-09 08:53, Michael Balzer wrote:
Yes, you need the new toolchain.
It's been published here:https://github.com/espressif/esp-idf/issues/2892#issuecomment-498965365
No FreeBSD port yet, I'm afraid.
I'm the port maintainer so all I need is access to the new source and I can update it. I'm also interested because I have an unrelated esp32 project that does https rest api calls when buttons are pressed and it has along term stability issues. I guess I just need to wait for them to decide they've fixed the issue before they release source... Craig
Since publishing the build with the new toolchain, the identifiable crashes have been concentrating within / around the LWIP / Wifi stacks. I have now upgraded to the latest toolchain update (https://github.com/espressif/esp-idf/issues/2892#issuecomment-501106283). As a new Wifi blob still isn't available, I have also disabled CONFIG_WIFI_LWIP_ALLOCATION_FROM_SPIRAM_FIRST to see if that helps. Internal memory use went up a bit, but totally acceptable. I'm going to publish the new build to my "edge" users now. Regards, Michael Am 05.06.19 um 20:57 schrieb Michael Balzer:
It *is* worth trying, Espressif just forgot to mention a necessary build config change.
Details: https://github.com/espressif/esp-idf/issues/2892#issuecomment-499184318
I've created a test branch for this: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commits/spi...
I'm now running the new version on both my modules, and they seem to be very stable up to now. Not a single websocket data corruption yet.
I'll publish the build to my "edge" users now.
Regards, Michael
Am 05.06.19 um 19:01 schrieb Michael Balzer:
Not worth trying yet.
It seems the toolchain libstdc++ hasn't been built with workaround, std::string is still broken.
Regards, Michael
Am 05.06.19 um 09:19 schrieb Mark Webb-Johnson:
FYI: Espressif have (finally) released a test toolchain for our PSRAM issue:
https://github.com/espressif/esp-idf/issues/2892
Linux <https://dl.espressif.com/dl/xtensa-esp32-elf-linux64-1.22.0-90-g26d9621-5.2.0-psramfix-20190605.tar.gz> Windows <https://dl.espressif.com/dl/xtensa-esp32-elf-win32-1.22.0-90-g26d9621-5.2.0-psramfix-20190605.tar.gz> OSX <https://dl.espressif.com/dl/xtensa-esp32-elf-macos-1.22.0-90-g26d9621-5.2.0-psramfix-20190605.tar.gz>
Apparently, we need to include the following flags:
|CFLAGS+=-mfix-esp32-psram-cache-dupldst CXXFLAGS+=-mfix-esp32-psram-cache-dupldst|
This is a preliminary test fix only, so not for general release, but worth trying.
Regards, Mark
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
participants (3)
-
Craig Leres -
Mark Webb-Johnson -
Michael Balzer