FYI: I've merged the current v3.3 status and am now running the new build (toolchain still 1.22.0-93-gf6c4cdf) on my modules. I though it would be easier to merge v3.2 first, but that didn't work out. The current v3.2 status seems to have a bug, it wouldn't link due to too many segments. The segments have been introduced by a wifi blob update to support a new wifi IRAM optimization, but that needs a linker script & esptool update as well, that seems to be available only in the v3.3 branch. So I merged v3.3 directly afterwards, and that builds without issues. So far I haven't noticed any relevant problems running the new build. On stopping the wifi module, two event errors get logged, and the AP network interface remains configured as up: OVMS# wifi mode off Stopping wifi station... I (1307252) esp32wifi: Stopping WIFI station I (1307252) netmanager: Interface priority is pp3 (10.170.195.13/255.255.255.255 gateway 10.64.64.64) I (1307252) netmanager: Set DNS#2 0.0.0.0 I (1307252) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority I (1307252) wifi: state: run -> init (0) I (1307262) wifi: pm stop, total sleep time: 1100678913 us / 1301859253 us I (1307262) wifi: new:<1,0>, old:<1,1>, ap:<1,1>, sta:<1,0>, prof:1 E (1307262) event: system_event_sta_disconnected_handle_default 294 esp_wifi_internal_reg_rxcb ret=0x3014 E (1307262) event: system_event_ap_stop_handle_default 223 esp_wifi_internal_reg_rxcb ret=0x3014 W (1307262) netmanager: CleanupConnections: can't get AP station list I (1307272) wifi: flush txq I (1307272) wifi: stop sw txq I (1307272) wifi: lmac stop hw txq I (1307292) time: Network was reconfigured: restarting SNTP client I (1307322) netmanager: Set DNS#2 0.0.0.0 I (1307322) esp32wifi: STA disconnected with reason 8 I (1307352) netmanager: Set DNS#2 0.0.0.0 I (1307392) netmanager: Set DNS#2 0.0.0.0 I (1307392) netmanager: WIFI access point is down I (1307392) esp32wifi: AP stopped OVMS# net status Interface#3: pp3 (ifup=1 linkup=1) IPv4: 10.170.195.13/255.255.255.255 gateway 10.64.64.64 Interface#2: ap2 (ifup=1 linkup=1) IPv4: 192.168.4.1/255.255.255.0 gateway 192.168.4.1 DNS: 192.168.2.1 192.168.2.1 Default Interface: pp3 (10.170.195.13/255.255.255.255 gateway 10.64.64.64) OVMS# But wifi is off, and after starting the wifi network again, everything works, so that's a minor issue. I'll do some more tests tomorrow, then push the update. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Update is pushed. Don't forget to do a submodule update in the esp-idf, I also recommend doing a "make clean" before the next build. Use the defaults for new config options, except: - disable SPIRAM_BANKSWITCH_ENABLE (bank switching for >4MiB external RAM) - disable FATFS_ALLOC_PREFER_EXTRAM (Perfer external RAM when allocating FATFS) Regards, Michael Am 20.07.19 um 23:21 schrieb Michael Balzer:
FYI: I've merged the current v3.3 status and am now running the new build (toolchain still 1.22.0-93-gf6c4cdf) on my modules.
I though it would be easier to merge v3.2 first, but that didn't work out. The current v3.2 status seems to have a bug, it wouldn't link due to too many segments. The segments have been introduced by a wifi blob update to support a new wifi IRAM optimization, but that needs a linker script & esptool update as well, that seems to be available only in the v3.3 branch.
So I merged v3.3 directly afterwards, and that builds without issues.
So far I haven't noticed any relevant problems running the new build. On stopping the wifi module, two event errors get logged, and the AP network interface remains configured as up:
OVMS# wifi mode off Stopping wifi station... I (1307252) esp32wifi: Stopping WIFI station I (1307252) netmanager: Interface priority is pp3 (10.170.195.13/255.255.255.255 gateway 10.64.64.64) I (1307252) netmanager: Set DNS#2 0.0.0.0 I (1307252) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority I (1307252) wifi: state: run -> init (0) I (1307262) wifi: pm stop, total sleep time: 1100678913 us / 1301859253 us I (1307262) wifi: new:<1,0>, old:<1,1>, ap:<1,1>, sta:<1,0>, prof:1 E (1307262) event: system_event_sta_disconnected_handle_default 294 esp_wifi_internal_reg_rxcb ret=0x3014 E (1307262) event: system_event_ap_stop_handle_default 223 esp_wifi_internal_reg_rxcb ret=0x3014 W (1307262) netmanager: CleanupConnections: can't get AP station list I (1307272) wifi: flush txq I (1307272) wifi: stop sw txq I (1307272) wifi: lmac stop hw txq I (1307292) time: Network was reconfigured: restarting SNTP client I (1307322) netmanager: Set DNS#2 0.0.0.0 I (1307322) esp32wifi: STA disconnected with reason 8 I (1307352) netmanager: Set DNS#2 0.0.0.0 I (1307392) netmanager: Set DNS#2 0.0.0.0 I (1307392) netmanager: WIFI access point is down I (1307392) esp32wifi: AP stopped OVMS# net status Interface#3: pp3 (ifup=1 linkup=1) IPv4: 10.170.195.13/255.255.255.255 gateway 10.64.64.64
Interface#2: ap2 (ifup=1 linkup=1) IPv4: 192.168.4.1/255.255.255.0 gateway 192.168.4.1
DNS: 192.168.2.1 192.168.2.1
Default Interface: pp3 (10.170.195.13/255.255.255.255 gateway 10.64.64.64) OVMS#
But wifi is off, and after starting the wifi network again, everything works, so that's a minor issue.
I'll do some more tests tomorrow, then push the update.
Regards, Michael
-- 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
Please note: a "git pull" will not work to update your local esp-idf. I had to reset the master branch to a previous commit to undo the revert of the last update attempt. So origin/master is now basically a new branch. A fresh clone is always an option, but resyncing your local master branch to origin/master should do as well: git fetch git checkout -fB master origin/master git submodule update --recursive Regards, Michael Am 21.07.19 um 21:33 schrieb Michael Balzer:
Update is pushed.
Don't forget to do a submodule update in the esp-idf, I also recommend doing a "make clean" before the next build.
Use the defaults for new config options, except: - disable SPIRAM_BANKSWITCH_ENABLE (bank switching for >4MiB external RAM) - disable FATFS_ALLOC_PREFER_EXTRAM (Perfer external RAM when allocating FATFS)
Regards, Michael
Am 20.07.19 um 23:21 schrieb Michael Balzer:
FYI: I've merged the current v3.3 status and am now running the new build (toolchain still 1.22.0-93-gf6c4cdf) on my modules.
I though it would be easier to merge v3.2 first, but that didn't work out. The current v3.2 status seems to have a bug, it wouldn't link due to too many segments. The segments have been introduced by a wifi blob update to support a new wifi IRAM optimization, but that needs a linker script & esptool update as well, that seems to be available only in the v3.3 branch.
So I merged v3.3 directly afterwards, and that builds without issues.
So far I haven't noticed any relevant problems running the new build. On stopping the wifi module, two event errors get logged, and the AP network interface remains configured as up:
OVMS# wifi mode off Stopping wifi station... I (1307252) esp32wifi: Stopping WIFI station I (1307252) netmanager: Interface priority is pp3 (10.170.195.13/255.255.255.255 gateway 10.64.64.64) I (1307252) netmanager: Set DNS#2 0.0.0.0 I (1307252) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority I (1307252) wifi: state: run -> init (0) I (1307262) wifi: pm stop, total sleep time: 1100678913 us / 1301859253 us I (1307262) wifi: new:<1,0>, old:<1,1>, ap:<1,1>, sta:<1,0>, prof:1 E (1307262) event: system_event_sta_disconnected_handle_default 294 esp_wifi_internal_reg_rxcb ret=0x3014 E (1307262) event: system_event_ap_stop_handle_default 223 esp_wifi_internal_reg_rxcb ret=0x3014 W (1307262) netmanager: CleanupConnections: can't get AP station list I (1307272) wifi: flush txq I (1307272) wifi: stop sw txq I (1307272) wifi: lmac stop hw txq I (1307292) time: Network was reconfigured: restarting SNTP client I (1307322) netmanager: Set DNS#2 0.0.0.0 I (1307322) esp32wifi: STA disconnected with reason 8 I (1307352) netmanager: Set DNS#2 0.0.0.0 I (1307392) netmanager: Set DNS#2 0.0.0.0 I (1307392) netmanager: WIFI access point is down I (1307392) esp32wifi: AP stopped OVMS# net status Interface#3: pp3 (ifup=1 linkup=1) IPv4: 10.170.195.13/255.255.255.255 gateway 10.64.64.64
Interface#2: ap2 (ifup=1 linkup=1) IPv4: 192.168.4.1/255.255.255.0 gateway 192.168.4.1
DNS: 192.168.2.1 192.168.2.1
Default Interface: pp3 (10.170.195.13/255.255.255.255 gateway 10.64.64.64) OVMS#
But wifi is off, and after starting the wifi network again, everything works, so that's a minor issue.
I'll do some more tests tomorrow, then push the update.
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Michael, Some comments / questions: Works ok for me. But I still got a mess in esp-idf (submodules not updated, old dependency .d files still around, etc), so had to remove it and re-clone. Builds identify as: 3.2.002-141-g1dc82dd/ota_1/edge (build idf v3.1-dev-4770-ge97f72e Jul 22 2019 19:25:36) Is that correct? 3.1-dev-4770? Should it not be 3.3? Bluetooth is not building for me, so I disabled it for the moment (it wasn’t enabled on the main build server anyway - just local development). Better to let espresso stabilise first before trying that again - just too many bugs and idiosyncratic behaviour. What is the current status of the toolchain with the PSRAM memory corruption fix? I see they released a newer version but you said it caused endless boot loop? Are you still running the version before that? Any point for us to change our public build system to it? Regards, Mark.
On 22 Jul 2019, at 3:04 PM, Michael Balzer <dexter@expeedo.de> wrote:
Please note: a "git pull" will not work to update your local esp-idf.
I had to reset the master branch to a previous commit to undo the revert of the last update attempt. So origin/master is now basically a new branch.
A fresh clone is always an option, but resyncing your local master branch to origin/master should do as well: git fetch git checkout -fB master origin/master git submodule update --recursive
Regards, Michael
Am 21.07.19 um 21:33 schrieb Michael Balzer:
Update is pushed.
Don't forget to do a submodule update in the esp-idf, I also recommend doing a "make clean" before the next build.
Use the defaults for new config options, except: - disable SPIRAM_BANKSWITCH_ENABLE (bank switching for >4MiB external RAM) - disable FATFS_ALLOC_PREFER_EXTRAM (Perfer external RAM when allocating FATFS)
Regards, Michael
Am 20.07.19 um 23:21 schrieb Michael Balzer:
FYI: I've merged the current v3.3 status and am now running the new build (toolchain still 1.22.0-93-gf6c4cdf) on my modules.
I though it would be easier to merge v3.2 first, but that didn't work out. The current v3.2 status seems to have a bug, it wouldn't link due to too many segments. The segments have been introduced by a wifi blob update to support a new wifi IRAM optimization, but that needs a linker script & esptool update as well, that seems to be available only in the v3.3 branch.
So I merged v3.3 directly afterwards, and that builds without issues.
So far I haven't noticed any relevant problems running the new build. On stopping the wifi module, two event errors get logged, and the AP network interface remains configured as up: OVMS# wifi mode off Stopping wifi station... I (1307252) esp32wifi: Stopping WIFI station I (1307252) netmanager: Interface priority is pp3 (10.170.195.13/255.255.255.255 gateway 10.64.64.64) I (1307252) netmanager: Set DNS#2 0.0.0.0 I (1307252) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority I (1307252) wifi: state: run -> init (0) I (1307262) wifi: pm stop, total sleep time: 1100678913 us / 1301859253 us I (1307262) wifi: new:<1,0>, old:<1,1>, ap:<1,1>, sta:<1,0>, prof:1 E (1307262) event: system_event_sta_disconnected_handle_default 294 esp_wifi_internal_reg_rxcb ret=0x3014 E (1307262) event: system_event_ap_stop_handle_default 223 esp_wifi_internal_reg_rxcb ret=0x3014 W (1307262) netmanager: CleanupConnections: can't get AP station list I (1307272) wifi: flush txq I (1307272) wifi: stop sw txq I (1307272) wifi: lmac stop hw txq I (1307292) time: Network was reconfigured: restarting SNTP client I (1307322) netmanager: Set DNS#2 0.0.0.0 I (1307322) esp32wifi: STA disconnected with reason 8 I (1307352) netmanager: Set DNS#2 0.0.0.0 I (1307392) netmanager: Set DNS#2 0.0.0.0 I (1307392) netmanager: WIFI access point is down I (1307392) esp32wifi: AP stopped OVMS# net status Interface#3: pp3 (ifup=1 linkup=1) IPv4: 10.170.195.13/255.255.255.255 gateway 10.64.64.64
Interface#2: ap2 (ifup=1 linkup=1) IPv4: 192.168.4.1/255.255.255.0 gateway 192.168.4.1
DNS: 192.168.2.1 192.168.2.1
Default Interface: pp3 (10.170.195.13/255.255.255.255 gateway 10.64.64.64) OVMS#
But wifi is off, and after starting the wifi network again, everything works, so that's a minor issue.
I'll do some more tests tomorrow, then push the update.
Regards, Michael
-- 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
Mark, Am 22.07.19 um 13:38 schrieb Mark Webb-Johnson:
Works ok for me. But I still got a mess in esp-idf (submodules not updated, old dependency .d files still around, etc), so had to remove it and re-clone.
Builds identify as:3.2.002-141-g1dc82dd/ota_1/edge (build idf v3.1-dev-4770-ge97f72e Jul 22 2019 19:25:36)
Is that correct? 3.1-dev-4770? Should it not be 3.3?
That should be fixed by a "make clean" (read: did it for me). On the spiram test branch, this is my current state: 3.2.002-150-g185b2fb4/ota_1/edge (build idf v3.3-beta3-770-ge97f72ea2 Jul 21 2019 21:29:40)
Bluetooth is not building for me, so I disabled it for the moment (it wasn’t enabled on the main build server anyway - just local development). Better to let espresso stabilise first before trying that again - just too many bugs and idiosyncratic behaviour.
What is the current status of the toolchain with the PSRAM memory corruption fix? I see they released a newer version but you said it caused endless boot loop? Are you still running the version before that? Any point for us to change our public build system to it?
Trying the -95 version with this esp-idf is on my list, I currently still build my edge releases with -93. The -93 version has no issues and has quite some benefit on stability and speed, so I recommend switching. I'll test the -95 version this evening. The esp-idf blobs still are pre-fix builds though, we need to wait for Espressif here. Keeping LWIP and Wifi internal buffers away from PSRAM helps. Regards, Michael
Regards, Mark.
On 22 Jul 2019, at 3:04 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Please note: a "git pull" will not work to update your local esp-idf.
I had to reset the master branch to a previous commit to undo the revert of the last update attempt. So origin/master is now basically a new branch.
A fresh clone is always an option, but resyncing your local master branch to origin/master should do as well:
git fetch git checkout -fB master origin/master git submodule update --recursive
Regards, Michael
Am 21.07.19 um 21:33 schrieb Michael Balzer:
Update is pushed.
Don't forget to do a submodule update in the esp-idf, I also recommend doing a "make clean" before the next build.
Use the defaults for new config options, except: - disable SPIRAM_BANKSWITCH_ENABLE (bank switching for >4MiB external RAM) - disable FATFS_ALLOC_PREFER_EXTRAM (Perfer external RAM when allocating FATFS)
Regards, Michael
Am 20.07.19 um 23:21 schrieb Michael Balzer:
FYI: I've merged the current v3.3 status and am now running the new build (toolchain still 1.22.0-93-gf6c4cdf) on my modules.
I though it would be easier to merge v3.2 first, but that didn't work out. The current v3.2 status seems to have a bug, it wouldn't link due to too many segments. The segments have been introduced by a wifi blob update to support a new wifi IRAM optimization, but that needs a linker script & esptool update as well, that seems to be available only in the v3.3 branch.
So I merged v3.3 directly afterwards, and that builds without issues.
So far I haven't noticed any relevant problems running the new build. On stopping the wifi module, two event errors get logged, and the AP network interface remains configured as up:
OVMS# wifi mode off Stopping wifi station... I (1307252) esp32wifi: Stopping WIFI station I (1307252) netmanager: Interface priority is pp3 (10.170.195.13/255.255.255.255 gateway 10.64.64.64) I (1307252) netmanager: Set DNS#2 0.0.0.0 I (1307252) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority I (1307252) wifi: state: run -> init (0) I (1307262) wifi: pm stop, total sleep time: 1100678913 us / 1301859253 us I (1307262) wifi: new:<1,0>, old:<1,1>, ap:<1,1>, sta:<1,0>, prof:1 E (1307262) event: system_event_sta_disconnected_handle_default 294 esp_wifi_internal_reg_rxcb ret=0x3014 E (1307262) event: system_event_ap_stop_handle_default 223 esp_wifi_internal_reg_rxcb ret=0x3014 W (1307262) netmanager: CleanupConnections: can't get AP station list I (1307272) wifi: flush txq I (1307272) wifi: stop sw txq I (1307272) wifi: lmac stop hw txq I (1307292) time: Network was reconfigured: restarting SNTP client I (1307322) netmanager: Set DNS#2 0.0.0.0 I (1307322) esp32wifi: STA disconnected with reason 8 I (1307352) netmanager: Set DNS#2 0.0.0.0 I (1307392) netmanager: Set DNS#2 0.0.0.0 I (1307392) netmanager: WIFI access point is down I (1307392) esp32wifi: AP stopped OVMS# net status Interface#3: pp3 (ifup=1 linkup=1) IPv4: 10.170.195.13/255.255.255.255 gateway 10.64.64.64
Interface#2: ap2 (ifup=1 linkup=1) IPv4: 192.168.4.1/255.255.255.0 gateway 192.168.4.1
DNS: 192.168.2.1 192.168.2.1
Default Interface: pp3 (10.170.195.13/255.255.255.255 gateway 10.64.64.64) OVMS#
But wifi is off, and after starting the wifi network again, everything works, so that's a minor issue.
I'll do some more tests tomorrow, then push the update.
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
That should be fixed by a "make clean" (read: did it for me).
For me, I needed a: $ cd ~/esp/esp-idf $ find ./tools/kconfig -name '*.d' -delete A google on the error (make dependency on limits.h) led me to the above and a comment from Espressif that this is a known issue hopefully fixed when they move to cmake.
On the spiram test branch, this is my current state: 3.2.002-150-g185b2fb4/ota_1/edge (build idf v3.3-beta3-770-ge97f72ea2 Jul 21 2019 21:29:40)
OK. I am still seeing: esp-idf mark$ git describe --always --tags --dirty v3.1-dev-4770-ge97f72ea2 esp-idf mark$ git remote -v origin https://github.com/openvehicles/esp-idf.git (fetch) origin https://github.com/openvehicles/esp-idf.git (push) esp-idf mark$ git branch -v * master e97f72ea2 Merge remote-tracking branch 'upstream/release/v3.3' What is yours showing for those? Are you sure you pushed the tags? Regards, Mark
On 22 Jul 2019, at 7:52 PM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
Am 22.07.19 um 13:38 schrieb Mark Webb-Johnson:
Works ok for me. But I still got a mess in esp-idf (submodules not updated, old dependency .d files still around, etc), so had to remove it and re-clone.
Builds identify as: 3.2.002-141-g1dc82dd/ota_1/edge (build idf v3.1-dev-4770-ge97f72e Jul 22 2019 19:25:36)
Is that correct? 3.1-dev-4770? Should it not be 3.3?
That should be fixed by a "make clean" (read: did it for me).
On the spiram test branch, this is my current state: 3.2.002-150-g185b2fb4/ota_1/edge (build idf v3.3-beta3-770-ge97f72ea2 Jul 21 2019 21:29:40)
Bluetooth is not building for me, so I disabled it for the moment (it wasn’t enabled on the main build server anyway - just local development). Better to let espresso stabilise first before trying that again - just too many bugs and idiosyncratic behaviour.
What is the current status of the toolchain with the PSRAM memory corruption fix? I see they released a newer version but you said it caused endless boot loop? Are you still running the version before that? Any point for us to change our public build system to it?
Trying the -95 version with this esp-idf is on my list, I currently still build my edge releases with -93.
The -93 version has no issues and has quite some benefit on stability and speed, so I recommend switching.
I'll test the -95 version this evening.
The esp-idf blobs still are pre-fix builds though, we need to wait for Espressif here. Keeping LWIP and Wifi internal buffers away from PSRAM helps.
Regards, Michael
Regards, Mark.
On 22 Jul 2019, at 3:04 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Please note: a "git pull" will not work to update your local esp-idf.
I had to reset the master branch to a previous commit to undo the revert of the last update attempt. So origin/master is now basically a new branch.
A fresh clone is always an option, but resyncing your local master branch to origin/master should do as well: git fetch git checkout -fB master origin/master git submodule update --recursive
Regards, Michael
Am 21.07.19 um 21:33 schrieb Michael Balzer:
Update is pushed.
Don't forget to do a submodule update in the esp-idf, I also recommend doing a "make clean" before the next build.
Use the defaults for new config options, except: - disable SPIRAM_BANKSWITCH_ENABLE (bank switching for >4MiB external RAM) - disable FATFS_ALLOC_PREFER_EXTRAM (Perfer external RAM when allocating FATFS)
Regards, Michael
Am 20.07.19 um 23:21 schrieb Michael Balzer:
FYI: I've merged the current v3.3 status and am now running the new build (toolchain still 1.22.0-93-gf6c4cdf) on my modules.
I though it would be easier to merge v3.2 first, but that didn't work out. The current v3.2 status seems to have a bug, it wouldn't link due to too many segments. The segments have been introduced by a wifi blob update to support a new wifi IRAM optimization, but that needs a linker script & esptool update as well, that seems to be available only in the v3.3 branch.
So I merged v3.3 directly afterwards, and that builds without issues.
So far I haven't noticed any relevant problems running the new build. On stopping the wifi module, two event errors get logged, and the AP network interface remains configured as up: OVMS# wifi mode off Stopping wifi station... I (1307252) esp32wifi: Stopping WIFI station I (1307252) netmanager: Interface priority is pp3 (10.170.195.13/255.255.255.255 gateway 10.64.64.64) I (1307252) netmanager: Set DNS#2 0.0.0.0 I (1307252) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority I (1307252) wifi: state: run -> init (0) I (1307262) wifi: pm stop, total sleep time: 1100678913 us / 1301859253 us I (1307262) wifi: new:<1,0>, old:<1,1>, ap:<1,1>, sta:<1,0>, prof:1 E (1307262) event: system_event_sta_disconnected_handle_default 294 esp_wifi_internal_reg_rxcb ret=0x3014 E (1307262) event: system_event_ap_stop_handle_default 223 esp_wifi_internal_reg_rxcb ret=0x3014 W (1307262) netmanager: CleanupConnections: can't get AP station list I (1307272) wifi: flush txq I (1307272) wifi: stop sw txq I (1307272) wifi: lmac stop hw txq I (1307292) time: Network was reconfigured: restarting SNTP client I (1307322) netmanager: Set DNS#2 0.0.0.0 I (1307322) esp32wifi: STA disconnected with reason 8 I (1307352) netmanager: Set DNS#2 0.0.0.0 I (1307392) netmanager: Set DNS#2 0.0.0.0 I (1307392) netmanager: WIFI access point is down I (1307392) esp32wifi: AP stopped OVMS# net status Interface#3: pp3 (ifup=1 linkup=1) IPv4: 10.170.195.13/255.255.255.255 gateway 10.64.64.64
Interface#2: ap2 (ifup=1 linkup=1) IPv4: 192.168.4.1/255.255.255.0 gateway 192.168.4.1
DNS: 192.168.2.1 192.168.2.1
Default Interface: pp3 (10.170.195.13/255.255.255.255 gateway 10.64.64.64) OVMS#
But wifi is off, and after starting the wifi network again, everything works, so that's a minor issue.
I'll do some more tests tomorrow, then push the update.
Regards, Michael
-- 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
Uh, I would have said "sure", but they are obviously missing (see branch select on https://github.com/openvehicles/esp-idf)… :-/ I'll push them this evening. Sorry… Michael Am 22.07.19 um 14:08 schrieb Mark Webb-Johnson:
That should be fixed by a "make clean" (read: did it for me).
For me, I needed a:
$ cd ~/esp/esp-idf
$ find ./tools/kconfig -name '*.d' -delete
A google on the error (make dependency on limits.h) led me to the above and a comment from Espressif that this is a known issue hopefully fixed when they move to cmake.
On the spiram test branch, this is my current state: 3.2.002-150-g185b2fb4/ota_1/edge (build idf v3.3-beta3-770-ge97f72ea2 Jul 21 2019 21:29:40)
OK. I am still seeing:
esp-idf mark$ git describe --always --tags --dirty
v3.1-dev-4770-ge97f72ea2
esp-idf mark$ git remote -v originhttps://github.com/openvehicles/esp-idf.git (fetch) originhttps://github.com/openvehicles/esp-idf.git (push)
esp-idf mark$ git branch -v * master e97f72ea2 Merge remote-tracking branch 'upstream/release/v3.3'
What is yours showing for those? Are you sure you pushed the tags?
Regards, Mark
On 22 Jul 2019, at 7:52 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
Am 22.07.19 um 13:38 schrieb Mark Webb-Johnson:
Works ok for me. But I still got a mess in esp-idf (submodules not updated, old dependency .d files still around, etc), so had to remove it and re-clone.
Builds identify as:3.2.002-141-g1dc82dd/ota_1/edge (build idf v3.1-dev-4770-ge97f72e Jul 22 2019 19:25:36)
Is that correct? 3.1-dev-4770? Should it not be 3.3?
That should be fixed by a "make clean" (read: did it for me).
On the spiram test branch, this is my current state: 3.2.002-150-g185b2fb4/ota_1/edge (build idf v3.3-beta3-770-ge97f72ea2 Jul 21 2019 21:29:40)
Bluetooth is not building for me, so I disabled it for the moment (it wasn’t enabled on the main build server anyway - just local development). Better to let espresso stabilise first before trying that again - just too many bugs and idiosyncratic behaviour.
What is the current status of the toolchain with the PSRAM memory corruption fix? I see they released a newer version but you said it caused endless boot loop? Are you still running the version before that? Any point for us to change our public build system to it?
Trying the -95 version with this esp-idf is on my list, I currently still build my edge releases with -93.
The -93 version has no issues and has quite some benefit on stability and speed, so I recommend switching.
I'll test the -95 version this evening.
The esp-idf blobs still are pre-fix builds though, we need to wait for Espressif here. Keeping LWIP and Wifi internal buffers away from PSRAM helps.
Regards, Michael
Regards, Mark.
On 22 Jul 2019, at 3:04 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Please note: a "git pull" will not work to update your local esp-idf.
I had to reset the master branch to a previous commit to undo the revert of the last update attempt. So origin/master is now basically a new branch.
A fresh clone is always an option, but resyncing your local master branch to origin/master should do as well:
git fetch git checkout -fB master origin/master git submodule update --recursive
Regards, Michael
Am 21.07.19 um 21:33 schrieb Michael Balzer:
Update is pushed.
Don't forget to do a submodule update in the esp-idf, I also recommend doing a "make clean" before the next build.
Use the defaults for new config options, except: - disable SPIRAM_BANKSWITCH_ENABLE (bank switching for >4MiB external RAM) - disable FATFS_ALLOC_PREFER_EXTRAM (Perfer external RAM when allocating FATFS)
Regards, Michael
Am 20.07.19 um 23:21 schrieb Michael Balzer:
FYI: I've merged the current v3.3 status and am now running the new build (toolchain still 1.22.0-93-gf6c4cdf) on my modules.
I though it would be easier to merge v3.2 first, but that didn't work out. The current v3.2 status seems to have a bug, it wouldn't link due to too many segments. The segments have been introduced by a wifi blob update to support a new wifi IRAM optimization, but that needs a linker script & esptool update as well, that seems to be available only in the v3.3 branch.
So I merged v3.3 directly afterwards, and that builds without issues.
So far I haven't noticed any relevant problems running the new build. On stopping the wifi module, two event errors get logged, and the AP network interface remains configured as up:
OVMS# wifi mode off Stopping wifi station... I (1307252) esp32wifi: Stopping WIFI station I (1307252) netmanager: Interface priority is pp3 (10.170.195.13/255.255.255.255 gateway 10.64.64.64) I (1307252) netmanager: Set DNS#2 0.0.0.0 I (1307252) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority I (1307252) wifi: state: run -> init (0) I (1307262) wifi: pm stop, total sleep time: 1100678913 us / 1301859253 us I (1307262) wifi: new:<1,0>, old:<1,1>, ap:<1,1>, sta:<1,0>, prof:1 E (1307262) event: system_event_sta_disconnected_handle_default 294 esp_wifi_internal_reg_rxcb ret=0x3014 E (1307262) event: system_event_ap_stop_handle_default 223 esp_wifi_internal_reg_rxcb ret=0x3014 W (1307262) netmanager: CleanupConnections: can't get AP station list I (1307272) wifi: flush txq I (1307272) wifi: stop sw txq I (1307272) wifi: lmac stop hw txq I (1307292) time: Network was reconfigured: restarting SNTP client I (1307322) netmanager: Set DNS#2 0.0.0.0 I (1307322) esp32wifi: STA disconnected with reason 8 I (1307352) netmanager: Set DNS#2 0.0.0.0 I (1307392) netmanager: Set DNS#2 0.0.0.0 I (1307392) netmanager: WIFI access point is down I (1307392) esp32wifi: AP stopped OVMS# net status Interface#3: pp3 (ifup=1 linkup=1) IPv4: 10.170.195.13/255.255.255.255 gateway 10.64.64.64
Interface#2: ap2 (ifup=1 linkup=1) IPv4: 192.168.4.1/255.255.255.0 gateway 192.168.4.1
DNS: 192.168.2.1 192.168.2.1
Default Interface: pp3 (10.170.195.13/255.255.255.255 gateway 10.64.64.64) OVMS#
But wifi is off, and after starting the wifi network again, everything works, so that's a minor issue.
I'll do some more tests tomorrow, then push the update.
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
If I had a dollar for every time I forgot the --tags… Glad it wasn’t me. I just found 'git config --global push.followTags true’. Perhaps that will make it automatic? Regards, Mark
On 22 Jul 2019, at 8:29 PM, Michael Balzer <dexter@expeedo.de> wrote:
Uh, I would have said "sure", but they are obviously missing (see branch select on https://github.com/openvehicles/esp-idf <https://github.com/openvehicles/esp-idf>)… :-/
I'll push them this evening.
Sorry… Michael
Am 22.07.19 um 14:08 schrieb Mark Webb-Johnson:
That should be fixed by a "make clean" (read: did it for me).
For me, I needed a:
$ cd ~/esp/esp-idf $ find ./tools/kconfig -name '*.d' -delete
A google on the error (make dependency on limits.h) led me to the above and a comment from Espressif that this is a known issue hopefully fixed when they move to cmake.
On the spiram test branch, this is my current state: 3.2.002-150-g185b2fb4/ota_1/edge (build idf v3.3-beta3-770-ge97f72ea2 Jul 21 2019 21:29:40)
OK. I am still seeing:
esp-idf mark$ git describe --always --tags --dirty v3.1-dev-4770-ge97f72ea2
esp-idf mark$ git remote -v origin https://github.com/openvehicles/esp-idf.git <https://github.com/openvehicles/esp-idf.git> (fetch) origin https://github.com/openvehicles/esp-idf.git <https://github.com/openvehicles/esp-idf.git> (push)
esp-idf mark$ git branch -v * master e97f72ea2 Merge remote-tracking branch 'upstream/release/v3.3'
What is yours showing for those? Are you sure you pushed the tags?
Regards, Mark
On 22 Jul 2019, at 7:52 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
Am 22.07.19 um 13:38 schrieb Mark Webb-Johnson:
Works ok for me. But I still got a mess in esp-idf (submodules not updated, old dependency .d files still around, etc), so had to remove it and re-clone.
Builds identify as: 3.2.002-141-g1dc82dd/ota_1/edge (build idf v3.1-dev-4770-ge97f72e Jul 22 2019 19:25:36)
Is that correct? 3.1-dev-4770? Should it not be 3.3?
That should be fixed by a "make clean" (read: did it for me).
On the spiram test branch, this is my current state: 3.2.002-150-g185b2fb4/ota_1/edge (build idf v3.3-beta3-770-ge97f72ea2 Jul 21 2019 21:29:40)
Bluetooth is not building for me, so I disabled it for the moment (it wasn’t enabled on the main build server anyway - just local development). Better to let espresso stabilise first before trying that again - just too many bugs and idiosyncratic behaviour.
What is the current status of the toolchain with the PSRAM memory corruption fix? I see they released a newer version but you said it caused endless boot loop? Are you still running the version before that? Any point for us to change our public build system to it?
Trying the -95 version with this esp-idf is on my list, I currently still build my edge releases with -93.
The -93 version has no issues and has quite some benefit on stability and speed, so I recommend switching.
I'll test the -95 version this evening.
The esp-idf blobs still are pre-fix builds though, we need to wait for Espressif here. Keeping LWIP and Wifi internal buffers away from PSRAM helps.
Regards, Michael
Regards, Mark.
On 22 Jul 2019, at 3:04 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Please note: a "git pull" will not work to update your local esp-idf.
I had to reset the master branch to a previous commit to undo the revert of the last update attempt. So origin/master is now basically a new branch.
A fresh clone is always an option, but resyncing your local master branch to origin/master should do as well: git fetch git checkout -fB master origin/master git submodule update --recursive
Regards, Michael
Am 21.07.19 um 21:33 schrieb Michael Balzer:
Update is pushed.
Don't forget to do a submodule update in the esp-idf, I also recommend doing a "make clean" before the next build.
Use the defaults for new config options, except: - disable SPIRAM_BANKSWITCH_ENABLE (bank switching for >4MiB external RAM) - disable FATFS_ALLOC_PREFER_EXTRAM (Perfer external RAM when allocating FATFS)
Regards, Michael
Am 20.07.19 um 23:21 schrieb Michael Balzer: > FYI: I've merged the current v3.3 status and am now running the new build (toolchain still 1.22.0-93-gf6c4cdf) on my modules. > > I though it would be easier to merge v3.2 first, but that didn't work out. The current v3.2 status seems to have a bug, it wouldn't link due to too many segments. The segments have been introduced by a wifi blob update to support a new wifi IRAM optimization, but that needs a linker script & esptool update as well, that seems to be available only in the v3.3 branch. > > So I merged v3.3 directly afterwards, and that builds without issues. > > So far I haven't noticed any relevant problems running the new build. On stopping the wifi module, two event errors get logged, and the AP network interface remains configured as up: > OVMS# wifi mode off > Stopping wifi station... > I (1307252) esp32wifi: Stopping WIFI station > I (1307252) netmanager: Interface priority is pp3 (10.170.195.13/255.255.255.255 gateway 10.64.64.64) > I (1307252) netmanager: Set DNS#2 0.0.0.0 > I (1307252) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority > I (1307252) wifi: state: run -> init (0) > I (1307262) wifi: pm stop, total sleep time: 1100678913 us / 1301859253 us > I (1307262) wifi: new:<1,0>, old:<1,1>, ap:<1,1>, sta:<1,0>, prof:1 > E (1307262) event: system_event_sta_disconnected_handle_default 294 esp_wifi_internal_reg_rxcb ret=0x3014 > E (1307262) event: system_event_ap_stop_handle_default 223 esp_wifi_internal_reg_rxcb ret=0x3014 > W (1307262) netmanager: CleanupConnections: can't get AP station list > I (1307272) wifi: flush txq > I (1307272) wifi: stop sw txq > I (1307272) wifi: lmac stop hw txq > I (1307292) time: Network was reconfigured: restarting SNTP client > I (1307322) netmanager: Set DNS#2 0.0.0.0 > I (1307322) esp32wifi: STA disconnected with reason 8 > I (1307352) netmanager: Set DNS#2 0.0.0.0 > I (1307392) netmanager: Set DNS#2 0.0.0.0 > I (1307392) netmanager: WIFI access point is down > I (1307392) esp32wifi: AP stopped > OVMS# net status > Interface#3: pp3 (ifup=1 linkup=1) > IPv4: 10.170.195.13/255.255.255.255 gateway 10.64.64.64 > > Interface#2: ap2 (ifup=1 linkup=1) > IPv4: 192.168.4.1/255.255.255.0 gateway 192.168.4.1 > > DNS: 192.168.2.1 192.168.2.1 > > Default Interface: pp3 (10.170.195.13/255.255.255.255 gateway 10.64.64.64) > OVMS# > > But wifi is off, and after starting the wifi network again, everything works, so that's a minor issue. > > I'll do some more tests tomorrow, then push the update. > > Regards, > Michael
-- 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
git remote add upstream https://github.com/espressif/esp-idf.git git fetch upstream worked for me Von: OvmsDev <ovmsdev-bounces@lists.openvehicles.com> Im Auftrag von Mark Webb-Johnson Gesendet: Montag, 22. Juli 2019 15:06 An: OVMS Developers <ovmsdev@lists.openvehicles.com> Betreff: Re: [Ovmsdev] esp-idf v3.3 If I had a dollar for every time I forgot the --tags… Glad it wasn’t me. I just found 'git config --global push.followTags true’. Perhaps that will make it automatic? Regards, Mark On 22 Jul 2019, at 8:29 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de> > wrote: Uh, I would have said "sure", but they are obviously missing (see branch select on https://github.com/openvehicles/esp-idf)… :-/ I'll push them this evening. Sorry… Michael Am 22.07.19 um 14:08 schrieb Mark Webb-Johnson: That should be fixed by a "make clean" (read: did it for me). For me, I needed a: $ cd ~/esp/esp-idf $ find ./tools/kconfig -name '*.d' -delete A google on the error (make dependency on limits.h) led me to the above and a comment from Espressif that this is a known issue hopefully fixed when they move to cmake. On the spiram test branch, this is my current state: 3.2.002-150-g185b2fb4/ota_1/edge (build idf v3.3-beta3-770-ge97f72ea2 Jul 21 2019 21:29:40) OK. I am still seeing: esp-idf mark$ git describe --always --tags --dirty v3.1-dev-4770-ge97f72ea2 esp-idf mark$ git remote -v origin https://github.com/openvehicles/esp-idf.git (fetch) origin https://github.com/openvehicles/esp-idf.git (push) esp-idf mark$ git branch -v * master e97f72ea2 Merge remote-tracking branch 'upstream/release/v3.3' What is yours showing for those? Are you sure you pushed the tags? Regards, Mark On 22 Jul 2019, at 7:52 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de> > wrote: Mark, Am 22.07.19 um 13:38 schrieb Mark Webb-Johnson: Works ok for me. But I still got a mess in esp-idf (submodules not updated, old dependency .d files still around, etc), so had to remove it and re-clone. Builds identify as: 3.2.002-141-g1dc82dd/ota_1/edge (build idf v3.1-dev-4770-ge97f72e Jul 22 2019 19:25:36) Is that correct? 3.1-dev-4770? Should it not be 3.3? That should be fixed by a "make clean" (read: did it for me). On the spiram test branch, this is my current state: 3.2.002-150-g185b2fb4/ota_1/edge (build idf v3.3-beta3-770-ge97f72ea2 Jul 21 2019 21:29:40) Bluetooth is not building for me, so I disabled it for the moment (it wasn’t enabled on the main build server anyway - just local development). Better to let espresso stabilise first before trying that again - just too many bugs and idiosyncratic behaviour. What is the current status of the toolchain with the PSRAM memory corruption fix? I see they released a newer version but you said it caused endless boot loop? Are you still running the version before that? Any point for us to change our public build system to it? Trying the -95 version with this esp-idf is on my list, I currently still build my edge releases with -93. The -93 version has no issues and has quite some benefit on stability and speed, so I recommend switching. I'll test the -95 version this evening. The esp-idf blobs still are pre-fix builds though, we need to wait for Espressif here. Keeping LWIP and Wifi internal buffers away from PSRAM helps. Regards, Michael Regards, Mark. On 22 Jul 2019, at 3:04 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de> > wrote: Please note: a "git pull" will not work to update your local esp-idf. I had to reset the master branch to a previous commit to undo the revert of the last update attempt. So origin/master is now basically a new branch. A fresh clone is always an option, but resyncing your local master branch to origin/master should do as well: git fetch git checkout -fB master origin/master git submodule update --recursive Regards, Michael Am 21.07.19 um 21:33 schrieb Michael Balzer: Update is pushed. Don't forget to do a submodule update in the esp-idf, I also recommend doing a "make clean" before the next build. Use the defaults for new config options, except: - disable SPIRAM_BANKSWITCH_ENABLE (bank switching for >4MiB external RAM) - disable FATFS_ALLOC_PREFER_EXTRAM (Perfer external RAM when allocating FATFS) Regards, Michael Am 20.07.19 um 23:21 schrieb Michael Balzer: FYI: I've merged the current v3.3 status and am now running the new build (toolchain still 1.22.0-93-gf6c4cdf) on my modules. I though it would be easier to merge v3.2 first, but that didn't work out. The current v3.2 status seems to have a bug, it wouldn't link due to too many segments. The segments have been introduced by a wifi blob update to support a new wifi IRAM optimization, but that needs a linker script & esptool update as well, that seems to be available only in the v3.3 branch. So I merged v3.3 directly afterwards, and that builds without issues. So far I haven't noticed any relevant problems running the new build. On stopping the wifi module, two event errors get logged, and the AP network interface remains configured as up: OVMS# wifi mode off Stopping wifi station... I (1307252) esp32wifi: Stopping WIFI station I (1307252) netmanager: Interface priority is pp3 (10.170.195.13/255.255.255.255 gateway 10.64.64.64) I (1307252) netmanager: Set DNS#2 0.0.0.0 I (1307252) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority I (1307252) wifi: state: run -> init (0) I (1307262) wifi: pm stop, total sleep time: 1100678913 us / 1301859253 us I (1307262) wifi: new:<1,0>, old:<1,1>, ap:<1,1>, sta:<1,0>, prof:1 E (1307262) event: system_event_sta_disconnected_handle_default 294 esp_wifi_internal_reg_rxcb ret=0x3014 E (1307262) event: system_event_ap_stop_handle_default 223 esp_wifi_internal_reg_rxcb ret=0x3014 W (1307262) netmanager: CleanupConnections: can't get AP station list I (1307272) wifi: flush txq I (1307272) wifi: stop sw txq I (1307272) wifi: lmac stop hw txq I (1307292) time: Network was reconfigured: restarting SNTP client I (1307322) netmanager: Set DNS#2 0.0.0.0 I (1307322) esp32wifi: STA disconnected with reason 8 I (1307352) netmanager: Set DNS#2 0.0.0.0 I (1307392) netmanager: Set DNS#2 0.0.0.0 I (1307392) netmanager: WIFI access point is down I (1307392) esp32wifi: AP stopped OVMS# net status Interface#3: pp3 (ifup=1 linkup=1) IPv4: 10.170.195.13/255.255.255.255 gateway 10.64.64.64 Interface#2: ap2 (ifup=1 linkup=1) IPv4: 192.168.4.1/255.255.255.0 gateway 192.168.4.1 DNS: 192.168.2.1 192.168.2.1 Default Interface: pp3 (10.170.195.13/255.255.255.255 gateway 10.64.64.64) OVMS# But wifi is off, and after starting the wifi network again, everything works, so that's a minor issue. I'll do some more tests tomorrow, then push the update. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Not sure what branch and/or remote you have selected, but it sounds like you would be using the Espressif branch, not our clone/fork, if you did that. Regards, Mark.
On 23 Jul 2019, at 1:48 AM, <egon@heuer-humfeld.de> <egon@heuer-humfeld.de> wrote:
git remote add upstream https://github.com/espressif/esp-idf.git <https://github.com/espressif/esp-idf.git> git fetch upstream worked for me
Von: OvmsDev <ovmsdev-bounces@lists.openvehicles.com <mailto:ovmsdev-bounces@lists.openvehicles.com>> Im Auftrag von Mark Webb-Johnson Gesendet: Montag, 22. Juli 2019 15:06 An: OVMS Developers <ovmsdev@lists.openvehicles.com <mailto:ovmsdev@lists.openvehicles.com>> Betreff: Re: [Ovmsdev] esp-idf v3.3
If I had a dollar for every time I forgot the --tags… Glad it wasn’t me.
I just found 'git config --global push.followTags true’. Perhaps that will make it automatic?
Regards, Mark
On 22 Jul 2019, at 8:29 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Uh, I would have said "sure", but they are obviously missing (see branch select on https://github.com/openvehicles/esp-idf <https://github.com/openvehicles/esp-idf>)… :-/
I'll push them this evening.
Sorry… Michael
Am 22.07.19 um 14:08 schrieb Mark Webb-Johnson:
That should be fixed by a "make clean" (read: did it for me).
For me, I needed a:
$ cd ~/esp/esp-idf $ find ./tools/kconfig -name '*.d' -delete
A google on the error (make dependency on limits.h) led me to the above and a comment from Espressif that this is a known issue hopefully fixed when they move to cmake.
On the spiram test branch, this is my current state: 3.2.002-150-g185b2fb4/ota_1/edge (build idf v3.3-beta3-770-ge97f72ea2 Jul 21 2019 21:29:40)
OK. I am still seeing:
esp-idf mark$ git describe --always --tags --dirty v3.1-dev-4770-ge97f72ea2
esp-idf mark$ git remote -v origin https://github.com/openvehicles/esp-idf.git <https://github.com/openvehicles/esp-idf.git> (fetch) origin https://github.com/openvehicles/esp-idf.git <https://github.com/openvehicles/esp-idf.git> (push)
esp-idf mark$ git branch -v * master e97f72ea2 Merge remote-tracking branch 'upstream/release/v3.3'
What is yours showing for those? Are you sure you pushed the tags?
Regards, Mark
On 22 Jul 2019, at 7:52 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
Am 22.07.19 um 13:38 schrieb Mark Webb-Johnson:
Works ok for me. But I still got a mess in esp-idf (submodules not updated, old dependency .d files still around, etc), so had to remove it and re-clone.
Builds identify as: 3.2.002-141-g1dc82dd/ota_1/edge (build idf v3.1-dev-4770-ge97f72e Jul 22 2019 19:25:36)
Is that correct? 3.1-dev-4770? Should it not be 3.3?
That should be fixed by a "make clean" (read: did it for me).
On the spiram test branch, this is my current state: 3.2.002-150-g185b2fb4/ota_1/edge (build idf v3.3-beta3-770-ge97f72ea2 Jul 21 2019 21:29:40)
Bluetooth is not building for me, so I disabled it for the moment (it wasn’t enabled on the main build server anyway - just local development). Better to let espresso stabilise first before trying that again - just too many bugs and idiosyncratic behaviour.
What is the current status of the toolchain with the PSRAM memory corruption fix? I see they released a newer version but you said it caused endless boot loop? Are you still running the version before that? Any point for us to change our public build system to it?
Trying the -95 version with this esp-idf is on my list, I currently still build my edge releases with -93.
The -93 version has no issues and has quite some benefit on stability and speed, so I recommend switching.
I'll test the -95 version this evening.
The esp-idf blobs still are pre-fix builds though, we need to wait for Espressif here. Keeping LWIP and Wifi internal buffers away from PSRAM helps.
Regards, Michael
Regards, Mark.
On 22 Jul 2019, at 3:04 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Please note: a "git pull" will not work to update your local esp-idf.
I had to reset the master branch to a previous commit to undo the revert of the last update attempt. So origin/master is now basically a new branch.
A fresh clone is always an option, but resyncing your local master branch to origin/master should do as well: > git fetch > git checkout -fB master origin/master > git submodule update --recursive
Regards, Michael
Am 21.07.19 um 21:33 schrieb Michael Balzer: > Update is pushed. > > Don't forget to do a submodule update in the esp-idf, I also recommend doing a "make clean" before the next build. > > Use the defaults for new config options, except: > - disable SPIRAM_BANKSWITCH_ENABLE (bank switching for >4MiB external RAM) > - disable FATFS_ALLOC_PREFER_EXTRAM (Perfer external RAM when allocating FATFS) > > Regards, > Michael > > > Am 20.07.19 um 23:21 schrieb Michael Balzer: >> FYI: I've merged the current v3.3 status and am now running the new build (toolchain still 1.22.0-93-gf6c4cdf) on my modules. >> >> I though it would be easier to merge v3.2 first, but that didn't work out. The current v3.2 status seems to have a bug, it wouldn't link due to too many segments. The segments have been introduced by a wifi blob update to support a new wifi IRAM optimization, but that needs a linker script & esptool update as well, that seems to be available only in the v3.3 branch. >> >> So I merged v3.3 directly afterwards, and that builds without issues. >> >> So far I haven't noticed any relevant problems running the new build. On stopping the wifi module, two event errors get logged, and the AP network interface remains configured as up: >>> OVMS# wifi mode off >>> Stopping wifi station... >>> I (1307252) esp32wifi: Stopping WIFI station >>> I (1307252) netmanager: Interface priority is pp3 (10.170.195.13/255.255.255.255 gateway 10.64.64.64) >>> I (1307252) netmanager: Set DNS#2 0.0.0.0 >>> I (1307252) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority >>> I (1307252) wifi: state: run -> init (0) >>> I (1307262) wifi: pm stop, total sleep time: 1100678913 us / 1301859253 us >>> I (1307262) wifi: new:<1,0>, old:<1,1>, ap:<1,1>, sta:<1,0>, prof:1 >>> E (1307262) event: system_event_sta_disconnected_handle_default 294 esp_wifi_internal_reg_rxcb ret=0x3014 >>> E (1307262) event: system_event_ap_stop_handle_default 223 esp_wifi_internal_reg_rxcb ret=0x3014 >>> W (1307262) netmanager: CleanupConnections: can't get AP station list >>> I (1307272) wifi: flush txq >>> I (1307272) wifi: stop sw txq >>> I (1307272) wifi: lmac stop hw txq >>> I (1307292) time: Network was reconfigured: restarting SNTP client >>> I (1307322) netmanager: Set DNS#2 0.0.0.0 >>> I (1307322) esp32wifi: STA disconnected with reason 8 >>> I (1307352) netmanager: Set DNS#2 0.0.0.0 >>> I (1307392) netmanager: Set DNS#2 0.0.0.0 >>> I (1307392) netmanager: WIFI access point is down >>> I (1307392) esp32wifi: AP stopped >>> OVMS# net status >>> Interface#3: pp3 (ifup=1 linkup=1) >>> IPv4: 10.170.195.13/255.255.255.255 gateway 10.64.64.64 >>> >>> Interface#2: ap2 (ifup=1 linkup=1) >>> IPv4: 192.168.4.1/255.255.255.0 gateway 192.168.4.1 >>> >>> DNS: 192.168.2.1 192.168.2.1 >>> >>> Default Interface: pp3 (10.170.195.13/255.255.255.255 gateway 10.64.64.64) >>> OVMS# >> >> But wifi is off, and after starting the wifi network again, everything works, so that's a minor issue. >> >> I'll do some more tests tomorrow, then push the update. >> >> Regards, >> Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
FYI, I just pushed a fix -- v3.3 PPPoS needs an explicit request to deliver DNS addresses, that's why modem connectivity was gone unless you had configured DNS addresses manually. The new idf seems to produce more crashes than the previous version. I've had a couple crashes myself this week, most of them not within our code (it seems). There are also reports on the new version destroying the config store once again. Here's a user backtrace of another crash event: 0x40105690 is in _fwrite_r (../../../.././newlib/libc/stdio/fwrite.c:168). 0x40105729 is in fwrite (../../../.././newlib/libc/stdio/fwrite.c:211). 206 in ../../../.././newlib/libc/stdio/fwrite.c 0x400f755b is in OvmsCommandApp::LogBuffer(LogBuffers*, char const*, __va_list_tag) (/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_command.cpp:851). 846 time_t rawtime; 847 time(&rawtime); 848 struct tm* tmu = localtime(&rawtime); 849 char tb[64]; 850 strftime(tb, sizeof(tb), "%Y-%m-%d %H:%M:%S %Z ", tmu); 851 m_logfile_size += fwrite(tb, 1, strlen(tb), m_logfile); So it crashed within the fwrite() for the log timestamp. That should not happen… :-/ Anyone else seeing similar issues? Regards, Michael Am 23.07.19 um 05:58 schrieb Mark Webb-Johnson:
Not sure what branch and/or remote you have selected, but it sounds like you would be using the Espressif branch, not our clone/fork, if you did that.
Regards, Mark.
On 23 Jul 2019, at 1:48 AM, <egon@heuer-humfeld.de <mailto:egon@heuer-humfeld.de>> <egon@heuer-humfeld.de <mailto:egon@heuer-humfeld.de>> wrote:
git remote add upstream https://github.com/espressif/esp-idf.git git fetch upstream worked for me *Von:* OvmsDev <ovmsdev-bounces@lists.openvehicles.com <mailto:ovmsdev-bounces@lists.openvehicles.com>> *Im Auftrag von *Mark Webb-Johnson *Gesendet:* Montag, 22. Juli 2019 15:06 *An:* OVMS Developers <ovmsdev@lists.openvehicles.com <mailto:ovmsdev@lists.openvehicles.com>> *Betreff:* Re: [Ovmsdev] esp-idf v3.3 If I had a dollar for every time I forgot the --tags… Glad it wasn’t me. I just found 'git config --global push.followTags true’. Perhaps that will make it automatic? Regards, Mark
On 22 Jul 2019, at 8:29 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: Uh, I would have said "sure", but they are obviously missing (see branch select on https://github.com/openvehicles/esp-idf)… :-/
I'll push them this evening.
Sorry… Michael
Am 22.07.19 um 14:08 schrieb Mark Webb-Johnson:
That should be fixed by a "make clean" (read: did it for me). For me, I needed a: $ cd ~/esp/esp-idf $ find ./tools/kconfig -name '*.d' -delete A google on the error (make dependency on limits.h) led me to the above and a comment from Espressif that this is a known issue hopefully fixed when they move to cmake. On the spiram test branch, this is my current state: 3.2.002-150-g185b2fb4/ota_1/edge (build idf v3.3-beta3-770-ge97f72ea2 Jul 21 2019 21:29:40) OK. I am still seeing: esp-idf mark$ git describe --always --tags --dirty v3.1-dev-4770-ge97f72ea2 esp-idf mark$ git remote -v origin https://github.com/openvehicles/esp-idf.git (fetch) origin https://github.com/openvehicles/esp-idf.git (push) esp-idf mark$ git branch -v * master e97f72ea2 Merge remote-tracking branch 'upstream/release/v3.3' What is yours showing for those? Are you sure you pushed the tags? Regards, Mark
On 22 Jul 2019, at 7:52 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: Mark,
Am 22.07.19 um 13:38 schrieb Mark Webb-Johnson:
Works ok for me. But I still got a mess in esp-idf (submodules not updated, old dependency .d files still around, etc), so had to remove it and re-clone. Builds identify as: 3.2.002-141-g1dc82dd/ota_1/edge (build idf v3.1-dev-4770-ge97f72e Jul 22 2019 19:25:36) Is that correct? 3.1-dev-4770? Should it not be 3.3?
That should be fixed by a "make clean" (read: did it for me).
On the spiram test branch, this is my current state: 3.2.002-150-g185b2fb4/ota_1/edge (build idf v3.3-beta3-770-ge97f72ea2 Jul 21 2019 21:29:40)
Bluetooth is not building for me, so I disabled it for the moment (it wasn’t enabled on the main build server anyway - just local development). Better to let espresso stabilise first before trying that again - just too many bugs and idiosyncratic behaviour. What is the current status of the toolchain with the PSRAM memory corruption fix? I see they released a newer version but you said it caused endless boot loop? Are you still running the version before that? Any point for us to change our public build system to it?
Trying the -95 version with this esp-idf is on my list, I currently still build my edge releases with -93.
The -93 version has no issues and has quite some benefit on stability and speed, so I recommend switching.
I'll test the -95 version this evening.
The esp-idf blobs still are pre-fix builds though, we need to wait for Espressif here. Keeping LWIP and Wifi internal buffers away from PSRAM helps.
Regards, Michael
Regards, Mark.
> On 22 Jul 2019, at 3:04 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: > > Please note: a "git pull" will not work to update your local esp-idf. > > I had to reset the master branch to a previous commit to undo the revert of the last update attempt. So origin/master is now basically a new branch. > > A fresh clone is always an option, but resyncing your local master branch to origin/master should do as well: >> git fetch >> git checkout -fB master origin/master >> git submodule update --recursive > > Regards, > Michael > > > Am 21.07.19 um 21:33 schrieb Michael Balzer: >> >> Update is pushed. >> >> Don't forget to do a submodule update in the esp-idf, I also recommend doing a "make clean" before the next build. >> >> Use the defaults for new config options, except: >> - disable SPIRAM_BANKSWITCH_ENABLE (bank switching for >4MiB external RAM) >> - disable FATFS_ALLOC_PREFER_EXTRAM (Perfer external RAM when allocating FATFS) >> >> Regards, >> Michael >> >> Am 20.07.19 um 23:21 schrieb Michael Balzer: >>> FYI: I've merged the current v3.3 status and am now running the new build (toolchain still 1.22.0-93-gf6c4cdf) on my modules. >>> >>> I though it would be easier to merge v3.2 first, but that didn't work out. The current v3.2 status seems to have a bug, it wouldn't link due to too >>> many segments. The segments have been introduced by a wifi blob update to support a new wifi IRAM optimization, but that needs a linker script & >>> esptool update as well, that seems to be available only in the v3.3 branch. >>> >>> So I merged v3.3 directly afterwards, and that builds without issues. >>> >>> So far I haven't noticed any relevant problems running the new build. On stopping the wifi module, two event errors get logged, and the AP network >>> interface remains configured as up: >>>> OVMS# wifi mode off >>>> Stopping wifi station... >>>> I (1307252) esp32wifi: Stopping WIFI station >>>> I (1307252) netmanager: Interface priority is pp3 (10.170.195.13/255.255.255.255 gateway 10.64.64.64) >>>> I (1307252) netmanager: Set DNS#2 0.0.0.0 >>>> I (1307252) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority >>>> I (1307252) wifi: state: run -> init (0) >>>> I (1307262) wifi: pm stop, total sleep time: 1100678913 us / 1301859253 us >>>> I (1307262) wifi: new:<1,0>, old:<1,1>, ap:<1,1>, sta:<1,0>, prof:1 >>>> E (1307262) event: system_event_sta_disconnected_handle_default 294 esp_wifi_internal_reg_rxcb ret=0x3014 >>>> E (1307262) event: system_event_ap_stop_handle_default 223 esp_wifi_internal_reg_rxcb ret=0x3014 >>>> W (1307262) netmanager: CleanupConnections: can't get AP station list >>>> I (1307272) wifi: flush txq >>>> I (1307272) wifi: stop sw txq >>>> I (1307272) wifi: lmac stop hw txq >>>> I (1307292) time: Network was reconfigured: restarting SNTP client >>>> I (1307322) netmanager: Set DNS#2 0.0.0.0 >>>> I (1307322) esp32wifi: STA disconnected with reason 8 >>>> I (1307352) netmanager: Set DNS#2 0.0.0.0 >>>> I (1307392) netmanager: Set DNS#2 0.0.0.0 >>>> I (1307392) netmanager: WIFI access point is down >>>> I (1307392) esp32wifi: AP stopped >>>> OVMS# net status >>>> Interface#3: pp3 (ifup=1 linkup=1) >>>> IPv4: 10.170.195.13/255.255.255.255 gateway 10.64.64.64 >>>> >>>> Interface#2: ap2 (ifup=1 linkup=1) >>>> IPv4: 192.168.4.1/255.255.255.0 gateway 192.168.4.1 >>>> >>>> DNS: 192.168.2.1 192.168.2.1 >>>> >>>> Default Interface: pp3 (10.170.195.13/255.255.255.255 gateway 10.64.64.64) >>>> OVMS# >>> >>> But wifi is off, and after starting the wifi network again, everything works, so that's a minor issue. >>> >>> I'll do some more tests tomorrow, then push the update. >>> >>> Regards, >>> Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ 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-07-26 07:02, Michael Balzer wrote:
FYI, I just pushed a fix -- v3.3 PPPoS needs an explicit request to deliver DNS addresses, that's why modem connectivity was gone unless you had configured DNS addresses manually.
I just did: git pull git submodule update but did not see any changes. Last change I see was July 20th: ice 564 % git log | head -4 commit e97f72ea24d2377033d0d0c2c83ff39dfa4b338e Merge: 40f01ec30 91f29bef1 Author: Michael Balzer <balzer@expeedo.de> Date: Sat Jul 20 22:11:10 2019 +0200 Does this tell you enough about my tree? ice 564 % git remote show origin * remote origin Fetch URL: https://github.com/openvehicles/esp-idf.git Push URL: https://github.com/openvehicles/esp-idf.git HEAD branch: master Remote branches: feature/psram_malloc tracked master tracked release/v2.0 tracked release/v2.1 tracked release/v3.0 tracked sntp-extension tracked Local branch configured for 'git pull': master merges with remote master Local ref configured for 'git push': master pushes to master (up to date) Or maybe you updated a different branch?
The new idf seems to produce more crashes than the previous version.
That's funny, a week ago I picked up the change Mark made to fix tcpserver and tcpclient related crash issues and I also updated the the esp-idf v3.3 and both of my car modules have been rock solid ever since. Craig
Craig, I meant an update to the OVMS, not the esp-idf. Am 26.07.19 um 23:05 schrieb Craig Leres:
The new idf seems to produce more crashes than the previous version.
That's funny, a week ago I picked up the change Mark made to fix tcpserver and tcpclient related crash issues and I also updated the the esp-idf v3.3 and both of my car modules have been rock solid ever since.
Not sure about the source of the crashes, may be related to specific operations. I had the impression there were more after I activated the SD log to debug the connectivity issue. Just checked my debugcrash.csv: I had six crashes this week, different places, types & cores. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Yup… I'll give that config a try. After github was down in the early evening, it's now been receptive and the tags are up to date now. A "git fetch" should be sufficient to retrieve the tags. Regards, Michael Am 22.07.19 um 15:05 schrieb Mark Webb-Johnson:
If I had a dollar for every time I forgot the --tags… Glad it wasn’t me.
I just found 'git config --global push.followTags true’. Perhaps that will make it automatic?
Regards, Mark
On 22 Jul 2019, at 8:29 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Uh, I would have said "sure", but they are obviously missing (see branch select on https://github.com/openvehicles/esp-idf)… :-/
I'll push them this evening.
Sorry… Michael
Am 22.07.19 um 14:08 schrieb Mark Webb-Johnson:
That should be fixed by a "make clean" (read: did it for me).
For me, I needed a:
$ cd ~/esp/esp-idf
$ find ./tools/kconfig -name '*.d' -delete
A google on the error (make dependency on limits.h) led me to the above and a comment from Espressif that this is a known issue hopefully fixed when they move to cmake.
On the spiram test branch, this is my current state: 3.2.002-150-g185b2fb4/ota_1/edge (build idf v3.3-beta3-770-ge97f72ea2 Jul 21 2019 21:29:40)
OK. I am still seeing:
esp-idf mark$ git describe --always --tags --dirty
v3.1-dev-4770-ge97f72ea2
esp-idf mark$ git remote -v originhttps://github.com/openvehicles/esp-idf.git (fetch) originhttps://github.com/openvehicles/esp-idf.git (push)
esp-idf mark$ git branch -v * master e97f72ea2 Merge remote-tracking branch 'upstream/release/v3.3'
What is yours showing for those? Are you sure you pushed the tags?
Regards, Mark
On 22 Jul 2019, at 7:52 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
Am 22.07.19 um 13:38 schrieb Mark Webb-Johnson:
Works ok for me. But I still got a mess in esp-idf (submodules not updated, old dependency .d files still around, etc), so had to remove it and re-clone.
Builds identify as:3.2.002-141-g1dc82dd/ota_1/edge (build idf v3.1-dev-4770-ge97f72e Jul 22 2019 19:25:36)
Is that correct? 3.1-dev-4770? Should it not be 3.3?
That should be fixed by a "make clean" (read: did it for me).
On the spiram test branch, this is my current state: 3.2.002-150-g185b2fb4/ota_1/edge (build idf v3.3-beta3-770-ge97f72ea2 Jul 21 2019 21:29:40)
Bluetooth is not building for me, so I disabled it for the moment (it wasn’t enabled on the main build server anyway - just local development). Better to let espresso stabilise first before trying that again - just too many bugs and idiosyncratic behaviour.
What is the current status of the toolchain with the PSRAM memory corruption fix? I see they released a newer version but you said it caused endless boot loop? Are you still running the version before that? Any point for us to change our public build system to it?
Trying the -95 version with this esp-idf is on my list, I currently still build my edge releases with -93.
The -93 version has no issues and has quite some benefit on stability and speed, so I recommend switching.
I'll test the -95 version this evening.
The esp-idf blobs still are pre-fix builds though, we need to wait for Espressif here. Keeping LWIP and Wifi internal buffers away from PSRAM helps.
Regards, Michael
Regards, Mark.
On 22 Jul 2019, at 3:04 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Please note: a "git pull" will not work to update your local esp-idf.
I had to reset the master branch to a previous commit to undo the revert of the last update attempt. So origin/master is now basically a new branch.
A fresh clone is always an option, but resyncing your local master branch to origin/master should do as well:
git fetch git checkout -fB master origin/master git submodule update --recursive
Regards, Michael
Am 21.07.19 um 21:33 schrieb Michael Balzer: > Update is pushed. > > Don't forget to do a submodule update in the esp-idf, I also recommend doing a "make clean" before the next build. > > Use the defaults for new config options, except: > - disable SPIRAM_BANKSWITCH_ENABLE (bank switching for >4MiB external RAM) > - disable FATFS_ALLOC_PREFER_EXTRAM (Perfer external RAM when allocating FATFS) > > Regards, > Michael > > > Am 20.07.19 um 23:21 schrieb Michael Balzer: >> FYI: I've merged the current v3.3 status and am now running the new build (toolchain still 1.22.0-93-gf6c4cdf) on my modules. >> >> I though it would be easier to merge v3.2 first, but that didn't work out. The current v3.2 status seems to have a bug, it wouldn't link due to too >> many segments. The segments have been introduced by a wifi blob update to support a new wifi IRAM optimization, but that needs a linker script & >> esptool update as well, that seems to be available only in the v3.3 branch. >> >> So I merged v3.3 directly afterwards, and that builds without issues. >> >> So far I haven't noticed any relevant problems running the new build. On stopping the wifi module, two event errors get logged, and the AP network >> interface remains configured as up: >> >> OVMS# wifi mode off >> Stopping wifi station... >> I (1307252) esp32wifi: Stopping WIFI station >> I (1307252) netmanager: Interface priority is pp3 (10.170.195.13/255.255.255.255 gateway 10.64.64.64) >> I (1307252) netmanager: Set DNS#2 0.0.0.0 >> I (1307252) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority >> I (1307252) wifi: state: run -> init (0) >> I (1307262) wifi: pm stop, total sleep time: 1100678913 us / 1301859253 us >> I (1307262) wifi: new:<1,0>, old:<1,1>, ap:<1,1>, sta:<1,0>, prof:1 >> E (1307262) event: system_event_sta_disconnected_handle_default 294 esp_wifi_internal_reg_rxcb ret=0x3014 >> E (1307262) event: system_event_ap_stop_handle_default 223 esp_wifi_internal_reg_rxcb ret=0x3014 >> W (1307262) netmanager: CleanupConnections: can't get AP station list >> I (1307272) wifi: flush txq >> I (1307272) wifi: stop sw txq >> I (1307272) wifi: lmac stop hw txq >> I (1307292) time: Network was reconfigured: restarting SNTP client >> I (1307322) netmanager: Set DNS#2 0.0.0.0 >> I (1307322) esp32wifi: STA disconnected with reason 8 >> I (1307352) netmanager: Set DNS#2 0.0.0.0 >> I (1307392) netmanager: Set DNS#2 0.0.0.0 >> I (1307392) netmanager: WIFI access point is down >> I (1307392) esp32wifi: AP stopped >> OVMS# net status >> Interface#3: pp3 (ifup=1 linkup=1) >> IPv4: 10.170.195.13/255.255.255.255 gateway 10.64.64.64 >> >> Interface#2: ap2 (ifup=1 linkup=1) >> IPv4: 192.168.4.1/255.255.255.0 gateway 192.168.4.1 >> >> DNS: 192.168.2.1 192.168.2.1 >> >> Default Interface: pp3 (10.170.195.13/255.255.255.255 gateway 10.64.64.64) >> OVMS# >> >> >> But wifi is off, and after starting the wifi network again, everything works, so that's a minor issue. >> >> I'll do some more tests tomorrow, then push the update. >> >> Regards, >> Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ 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
Am 22.07.19 um 13:52 schrieb Michael Balzer:
What is the current status of the toolchain with the PSRAM memory corruption fix? I see they released a newer version but you said it caused endless boot loop? Are you still running the version before that? Any point for us to change our public build system to it?
Trying the -95 version with this esp-idf is on my list, I currently still build my edge releases with -93.
The -93 version has no issues and has quite some benefit on stability and speed, so I recommend switching.
I'll test the -95 version this evening.
Works now, no boot crash loop. I'll post an update to the issue. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Sorry, too quick. I just started charging, and now my module keeps crashing. Do not use the -95 toolchain version. The -93 version works fine. Regards, Michael Am 22.07.19 um 21:43 schrieb Michael Balzer:
Am 22.07.19 um 13:52 schrieb Michael Balzer:
What is the current status of the toolchain with the PSRAM memory corruption fix? I see they released a newer version but you said it caused endless boot loop? Are you still running the version before that? Any point for us to change our public build system to it? Trying the -95 version with this esp-idf is on my list, I currently still build my edge releases with -93.
The -93 version has no issues and has quite some benefit on stability and speed, so I recommend switching.
I'll test the -95 version this evening. Works now, no boot crash loop.
I'll post an update to the issue.
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
participants (4)
-
Craig Leres -
egon＠heuer-humfeld.de -
Mark Webb-Johnson -
Michael Balzer