We are now 102 commits beyond 3.1.004. Time for a 3.1.005? I just want to get the CAC metric working for Tesla Roadster (which I should be able to get done today). After that, I am ready. Anything else blocking this release? OK to build? Regards, Mark
Let me also have a look at the clean SD unmount first (applying your new scheme), I'd rather have that fixed for 005. I also just got two new bug reports I'd like to check, I'll do that within the next 2-3 hours. Regards, Michael Am 01.05.2018 um 10:22 schrieb Mark Webb-Johnson:
We are now 102 commits beyond 3.1.004. Time for a 3.1.005?
I just want to get the CAC metric working for Tesla Roadster (which I should be able to get done today). After that, I am ready.
Anything else blocking this release? OK to build?
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
I’ve got some updates for Kia Soul that would have been nice to include in 005, but I’m not quite finished yet and I’m struggling with migrene today so I guess it’ll have to be for a future release. Just wanted to give a sign of live, since I’ve been awfully quiet lately 🙂 Geir
1. mai 2018 kl. 10:49 skrev Michael Balzer <dexter@expeedo.de>: Let me also have a look at the clean SD unmount first (applying your new scheme), I'd rather have that fixed for 005.
I also just got two new bug reports I'd like to check, I'll do that within the next 2-3 hours.
Regards, Michael
Am 01.05.2018 um 10:22 schrieb Mark Webb-Johnson:
We are now 102 commits beyond 3.1.004. Time for a 3.1.005?
I just want to get the CAC metric working for Tesla Roadster (which I should be able to get done today). After that, I am ready.
Anything else blocking this release? OK to build?
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
Hi! Did send a pull request now for changes for the Kia Soul. Should be more stable and a lot more useful than the previous. Geir
1. mai 2018 kl. 12:16 skrev Geir Øyvind Vælidalo <geir@validalo.net>:
I’ve got some updates for Kia Soul that would have been nice to include in 005, but I’m not quite finished yet and I’m struggling with migrene today so I guess it’ll have to be for a future release. Just wanted to give a sign of live, since I’ve been awfully quiet lately 🙂
Geir
1. mai 2018 kl. 10:49 skrev Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>>: Let me also have a look at the clean SD unmount first (applying your new scheme), I'd rather have that fixed for 005.
I also just got two new bug reports I'd like to check, I'll do that within the next 2-3 hours.
Regards, Michael
Am 01.05.2018 um 10:22 schrieb Mark Webb-Johnson:
We are now 102 commits beyond 3.1.004. Time for a 3.1.005?
I just want to get the CAC metric working for Tesla Roadster (which I should be able to get done today). After that, I am ready.
Anything else blocking this release? OK to build?
Regards, Mark
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto: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 <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Merged. Btw: to avoid this… … git rebase is your friend. My standard operation to pull in changes is "git pull --rebase --autostash". Regards, Michael Am 01.05.2018 um 13:58 schrieb Geir Øyvind Vælidalo:
Hi!
Did send a pull request now for changes for the Kia Soul. Should be more stable and a lot more useful than the previous.
Geir
1. mai 2018 kl. 12:16 skrev Geir Øyvind Vælidalo <geir@validalo.net <mailto:geir@validalo.net>>:
I’ve got some updates for Kia Soul that would have been nice to include in 005, but I’m not quite finished yet and I’m struggling with migrene today so I guess it’ll have to be for a future release. Just wanted to give a sign of live, since I’ve been awfully quiet lately 🙂
Geir
1. mai 2018 kl. 10:49 skrev Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>>: Let me also have a look at the clean SD unmount first (applying your new scheme), I'd rather have that fixed for 005.
I also just got two new bug reports I'd like to check, I'll do that within the next 2-3 hours.
Regards, Michael
Am 01.05.2018 um 10:22 schrieb Mark Webb-Johnson:
We are now 102 commits beyond 3.1.004. Time for a 3.1.005?
I just want to get the CAC metric working for Tesla Roadster (which I should be able to get done today). After that, I am ready.
Anything else blocking this release? OK to build?
Regards, Mark
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto: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 <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
Oh… Sorry, and thanks for the tip, Michael! Geir
1. mai 2018 kl. 14:42 skrev Michael Balzer <dexter@expeedo.de>:
Merged.
Btw: to avoid this…
<bdledbnfebdechkb.png>
… git rebase is your friend.
My standard operation to pull in changes is "git pull --rebase --autostash".
Regards, Michael
Am 01.05.2018 um 13:58 schrieb Geir Øyvind Vælidalo:
Hi!
Did send a pull request now for changes for the Kia Soul. Should be more stable and a lot more useful than the previous.
Geir
1. mai 2018 kl. 12:16 skrev Geir Øyvind Vælidalo <geir@validalo.net <mailto:geir@validalo.net>>:
I’ve got some updates for Kia Soul that would have been nice to include in 005, but I’m not quite finished yet and I’m struggling with migrene today so I guess it’ll have to be for a future release. Just wanted to give a sign of live, since I’ve been awfully quiet lately 🙂
Geir
1. mai 2018 kl. 10:49 skrev Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>>: Let me also have a look at the clean SD unmount first (applying your new scheme), I'd rather have that fixed for 005.
I also just got two new bug reports I'd like to check, I'll do that within the next 2-3 hours.
Regards, Michael
Am 01.05.2018 um 10:22 schrieb Mark Webb-Johnson:
We are now 102 commits beyond 3.1.004. Time for a 3.1.005?
I just want to get the CAC metric working for Tesla Roadster (which I should be able to get done today). After that, I am ready.
Anything else blocking this release? OK to build?
Regards, Mark
_______________________________________________ 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>
-- 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>
-- 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
I’ve sent a new pull request. How does it look now in git? Geir
1. mai 2018 kl. 14:59 skrev Geir Øyvind Vælidalo <geir@validalo.net>:
Oh… Sorry, and thanks for the tip, Michael!
Geir
1. mai 2018 kl. 14:42 skrev Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>>:
Merged.
Btw: to avoid this…
<bdledbnfebdechkb.png>
… git rebase is your friend.
My standard operation to pull in changes is "git pull --rebase --autostash".
Regards, Michael
Am 01.05.2018 um 13:58 schrieb Geir Øyvind Vælidalo:
Hi!
Did send a pull request now for changes for the Kia Soul. Should be more stable and a lot more useful than the previous.
Geir
1. mai 2018 kl. 12:16 skrev Geir Øyvind Vælidalo <geir@validalo.net <mailto:geir@validalo.net>>:
I’ve got some updates for Kia Soul that would have been nice to include in 005, but I’m not quite finished yet and I’m struggling with migrene today so I guess it’ll have to be for a future release. Just wanted to give a sign of live, since I’ve been awfully quiet lately 🙂
Geir
1. mai 2018 kl. 10:49 skrev Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>>: Let me also have a look at the clean SD unmount first (applying your new scheme), I'd rather have that fixed for 005.
I also just got two new bug reports I'd like to check, I'll do that within the next 2-3 hours.
Regards, Michael
Am 01.05.2018 um 10:22 schrieb Mark Webb-Johnson:
We are now 102 commits beyond 3.1.004. Time for a 3.1.005?
I just want to get the CAC metric working for Tesla Roadster (which I should be able to get done today). After that, I am ready.
Anything else blocking this release? OK to build?
Regards, Mark
_______________________________________________ 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>
-- 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>
-- 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
Mark, new SD unmount process is pushed. I have tested all standard paths but someone auditing my code would be good. As for the delay introduced by the modem shutdown, I think we can reduce some state timeouts. But that's low priority, the shutdown now works very nice and polite. The crash reports I got are RAM related. I don't know yet how this can still happen, one was a failed "new" operator in server_v2 for the message encryption, the other a failed mongoose buffer resize. Both modules should have plenty of free RAM now in about any situation, so I'm a bit clueless about these. Regards, Michael Am 01.05.2018 um 10:49 schrieb Michael Balzer:
Let me also have a look at the clean SD unmount first (applying your new scheme), I'd rather have that fixed for 005.
I also just got two new bug reports I'd like to check, I'll do that within the next 2-3 hours.
Regards, Michael
Am 01.05.2018 um 10:22 schrieb Mark Webb-Johnson:
We are now 102 commits beyond 3.1.004. Time for a 3.1.005?
I just want to get the CAC metric working for Tesla Roadster (which I should be able to get done today). After that, I am ready.
Anything else blocking this release? OK to build?
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
OK. v3.1.005 is built and out (in both edge and main). Regards, Mark.
On 1 May 2018, at 8:35 PM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
new SD unmount process is pushed. I have tested all standard paths but someone auditing my code would be good.
As for the delay introduced by the modem shutdown, I think we can reduce some state timeouts. But that's low priority, the shutdown now works very nice and polite.
The crash reports I got are RAM related. I don't know yet how this can still happen, one was a failed "new" operator in server_v2 for the message encryption, the other a failed mongoose buffer resize. Both modules should have plenty of free RAM now in about any situation, so I'm a bit clueless about these.
Regards, Michael
Am 01.05.2018 um 10:49 schrieb Michael Balzer:
Let me also have a look at the clean SD unmount first (applying your new scheme), I'd rather have that fixed for 005.
I also just got two new bug reports I'd like to check, I'll do that within the next 2-3 hours.
Regards, Michael
Am 01.05.2018 um 10:22 schrieb Mark Webb-Johnson:
We are now 102 commits beyond 3.1.004. Time for a 3.1.005?
I just want to get the CAC metric working for Tesla Roadster (which I should be able to get done today). After that, I am ready.
Anything else blocking this release? OK to build?
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
On Tue, 1 May 2018, Stephen Casner wrote:
On Tue, 1 May 2018, Mark Webb-Johnson wrote:
OK. v3.1.005 is built and out (in both edge and main).
While running 3.1.003, I just did flash from web, letting it default to the latest release. What I got was another copy of 3.1.003, not 3.1.005.
Oh, perhaps this result was because I have a v3.0 hardware module rather than v3.1? My second attempt was to go to the api.openvehicles.com/node/211 announcement of the v3.1.005 update and clicked on the "Latest Firmware" link. When I put the ovms3.bin file on my SD card and inserted it the software failed to boot up all the way, continuously looping to produce the output attached below. -- Steve rst:0xc (SW_CPU_RESET),boot:0x1f (SPI_FAST_FLASH_BOOT) configsip: 156795334, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:4584 load:0x40078000,len:0 ho 12 tail 0 room 4 load:0x40078000,len:13184 entry 0x40078d38 Guru Meditation Error: Core 0 panic'ed (IllegalInstruction) . Exception was unhandled. Core 0 register dump: PC : 0x400e05d4 PS : 0x00060530 A0 : 0x800ddf7f A1 : 0x3ffe3bd0 0x400e05d4: heap_bubble_down at /Users/casner/src/github/esp-idf/components/log/./log.c:299 A2 : 0x00000001 A3 : 0x00000001 A4 : 0x88000070 A5 : 0x3ff133fc A6 : 0x3ff00044 A7 : 0x00000080 A8 : 0x80084330 A9 : 0x3ff49050 A10 : 0x3ffe3bd0 A11 : 0x000000e1 A12 : 0x0ffd114c A13 : 0x00000000 A14 : 0x000000ff A15 : 0x00000001 SAR : 0x00000017 EXCCAUSE: 0x00000000 EXCVADDR: 0x00000000 LBEG : 0x40098a6c LEND : 0x40098a77 LCOUNT : 0x00000000 Backtrace: 0x400e05d4:0x3ffe3bd0 0x400ddf7c:0x3ffe3c00 0x40081602:0x3ffe3c20 0x40078aca:0x3ffe3c40 0x40078b7d:0x3ffe3c70 0x40078d11:0x3ffe3cb0 0x40078e5a:0x3ffe3e70 0x40007c31:0x3ffe3eb0 0x4000073d:0x3ffe3f20 0x400e05d4: heap_bubble_down at /Users/casner/src/github/esp-idf/components/log/./log.c:299 0x400ddf7c: heap_caps_check_integrity_all at /Users/casner/src/github/esp-idf/components/heap/./heap_caps.c:409 0x40081602: timer_insert at /Users/casner/src/github/esp-idf/components/esp32/./esp_timer.c:400 Rebooting... ets Jun 8 2016 00:22:57 rst:0xc (SW_CPU_RESET),boot:0x1f (SPI_FAST_FLASH_BOOT) configsip: 156795334, SPIWP:0x00 clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0008,len:8 load:0x3fff1150,len:3472 load:0x4147c154,len:273751932 1162 mmu set 00010000, pos 00010000 1162 mmu set 00020000, pos 00020000 1162 mmu set 00030000, pos 00030000 1162 mmu set 00040000, pos 00040000 1162 mmu set 00050000, pos 00050000 1162 mmu set 00060000, pos 00060000 1162 mmu set 00070000, pos 00070000 1162 mmu set 00080000, pos 00080000 1162 mmu set 00090000, pos 00090000 1162 mmu set 000a0000, pos 000a0000 1162 mmu set 000b0000, pos 000b0000 1162 mmu set 000c0000, pos 000c0000 1162 mmu set 000d0000, pos 000d0000 1162 mmu set 000e0000, pos 000e0000 1162 mmu set 000f0000, pos 000f0000 1162 mmu set 00100000, pos 00100000 1162 mmu set 00110000, pos 00110000 1162 mmu set 00120000, pos 00120000 1162 mmu set 00130000, pos 00130000 1162 mmu set 00140000, pos 00140000 1162 mmu set 00150000, pos 00150000 1162 mmu set 00160000, pos 00160000 1162 mmu set 00170000, pos 00170000 1162 mmu set 00180000, pos 00180000 1162 mmu set 00190000, pos 00190000 1162 mmu set 001a0000, pos 001a0000 1162 mmu set 001b0000, pos 001b0000 1162 mmu set 001c0000, pos 001c0000 1162 mmu set 001d0000, pos 001d0000 1162 mmu set 001e0000, pos 001e0000 1162 mmu set 001f0000, pos 001f0000 1162 mmu seets Jun 8 2016 00:22:57 rst:0x10 (RTCWDT_RTC_RESET),boot:0x1f (SPI_FAST_FLASH_BOOT) configsip: 156795334, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:4584 load:0x40078000,len:0 ho 12 tail 0 room 4 load:0x40078000,len:13184 entry 0x40078d38 Guru Meditation Error: Core 0 panic'ed (IllegalInstruction) . Exception was unhandled. Core 0 register dump: PC : 0x400e05d4 PS : 0x00060530 A0 : 0x800ddf7f A1 : 0x3ffe3bd0 0x400e05d4: heap_bubble_down at /Users/casner/src/github/esp-idf/components/log/./log.c:299 A2 : 0x00000001 A3 : 0x00000001 A4 : 0x88000070 A5 : 0x3ff133fc A6 : 0x3ff00044 A7 : 0x00000080 A8 : 0x80084330 A9 : 0x3ff49050 A10 : 0x3ffe3bd0 A11 : 0x000000e1 A12 : 0x0ffd114c A13 : 0x00000000 A14 : 0x000008ff A15 : 0x00000001 SAR : 0x00000017 EXCCAUSE: 0x00000000 EXCVADDR: 0x00000000 LBEG : 0x40098a6c LEND : 0x40098a77 LCOUNT : 0x00000000 Backtrace: 0x400e05d4:0x3ffe3bd0 0x400ddf7c:0x3ffe3c00 0x40081602:0x3ffe3c20 0x40078aca:0x3ffe3c40 0x40078b7d:0x3ffe3c70 0x40078d11:0x3ffe3cb0 0x40078e5a:0x3ffe3e70 0x40007c31:0x3ffe3eb0 0x4000073d:0x3ffe3f20 0x400e05d4: heap_bubble_down at /Users/casner/src/github/esp-idf/components/log/./log.c:299 0x400ddf7c: heap_caps_check_integrity_all at /Users/casner/src/github/esp-idf/components/heap/./heap_caps.c:409 0x40081602: timer_insert at /Users/casner/src/github/esp-idf/components/esp32/./esp_timer.c:400 Rebooting... ets Jun 8 2016 00:22:57
The continuing saga... No, this illegal instruction reboot loop is _not_ a consequence of the 3.1.005 ovms3.bin file being inappropriate for my v3.0 hardware. When I "git pull" and build with my own sdkconfig as before I get the same result. I'll try going back to an earlier commit to verify if some code change caused this behavior. -- Steve On Tue, 1 May 2018, Stephen Casner wrote:
On Tue, 1 May 2018, Stephen Casner wrote:
On Tue, 1 May 2018, Mark Webb-Johnson wrote:
OK. v3.1.005 is built and out (in both edge and main).
While running 3.1.003, I just did flash from web, letting it default to the latest release. What I got was another copy of 3.1.003, not 3.1.005.
Oh, perhaps this result was because I have a v3.0 hardware module rather than v3.1? My second attempt was to go to the api.openvehicles.com/node/211 announcement of the v3.1.005 update and clicked on the "Latest Firmware" link. When I put the ovms3.bin file on my SD card and inserted it the software failed to boot up all the way, continuously looping to produce the output attached below.
-- Steve
rst:0xc (SW_CPU_RESET),boot:0x1f (SPI_FAST_FLASH_BOOT) configsip: 156795334, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:4584 load:0x40078000,len:0 ho 12 tail 0 room 4 load:0x40078000,len:13184 entry 0x40078d38 Guru Meditation Error: Core 0 panic'ed (IllegalInstruction) . Exception was unhandled. Core 0 register dump: PC : 0x400e05d4 PS : 0x00060530 A0 : 0x800ddf7f A1 : 0x3ffe3bd0 0x400e05d4: heap_bubble_down at /Users/casner/src/github/esp-idf/components/log/./log.c:299
A2 : 0x00000001 A3 : 0x00000001 A4 : 0x88000070 A5 : 0x3ff133fc A6 : 0x3ff00044 A7 : 0x00000080 A8 : 0x80084330 A9 : 0x3ff49050 A10 : 0x3ffe3bd0 A11 : 0x000000e1 A12 : 0x0ffd114c A13 : 0x00000000 A14 : 0x000000ff A15 : 0x00000001 SAR : 0x00000017 EXCCAUSE: 0x00000000 EXCVADDR: 0x00000000 LBEG : 0x40098a6c LEND : 0x40098a77 LCOUNT : 0x00000000
Backtrace: 0x400e05d4:0x3ffe3bd0 0x400ddf7c:0x3ffe3c00 0x40081602:0x3ffe3c20 0x40078aca:0x3ffe3c40 0x40078b7d:0x3ffe3c70 0x40078d11:0x3ffe3cb0 0x40078e5a:0x3ffe3e70 0x40007c31:0x3ffe3eb0 0x4000073d:0x3ffe3f20 0x400e05d4: heap_bubble_down at /Users/casner/src/github/esp-idf/components/log/./log.c:299
0x400ddf7c: heap_caps_check_integrity_all at /Users/casner/src/github/esp-idf/components/heap/./heap_caps.c:409
0x40081602: timer_insert at /Users/casner/src/github/esp-idf/components/esp32/./esp_timer.c:400
Rebooting... ets Jun 8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x1f (SPI_FAST_FLASH_BOOT) configsip: 156795334, SPIWP:0x00 clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0008,len:8 load:0x3fff1150,len:3472 load:0x4147c154,len:273751932 1162 mmu set 00010000, pos 00010000 1162 mmu set 00020000, pos 00020000 1162 mmu set 00030000, pos 00030000 1162 mmu set 00040000, pos 00040000 1162 mmu set 00050000, pos 00050000 1162 mmu set 00060000, pos 00060000 1162 mmu set 00070000, pos 00070000 1162 mmu set 00080000, pos 00080000 1162 mmu set 00090000, pos 00090000 1162 mmu set 000a0000, pos 000a0000 1162 mmu set 000b0000, pos 000b0000 1162 mmu set 000c0000, pos 000c0000 1162 mmu set 000d0000, pos 000d0000 1162 mmu set 000e0000, pos 000e0000 1162 mmu set 000f0000, pos 000f0000 1162 mmu set 00100000, pos 00100000 1162 mmu set 00110000, pos 00110000 1162 mmu set 00120000, pos 00120000 1162 mmu set 00130000, pos 00130000 1162 mmu set 00140000, pos 00140000 1162 mmu set 00150000, pos 00150000 1162 mmu set 00160000, pos 00160000 1162 mmu set 00170000, pos 00170000 1162 mmu set 00180000, pos 00180000 1162 mmu set 00190000, pos 00190000 1162 mmu set 001a0000, pos 001a0000 1162 mmu set 001b0000, pos 001b0000 1162 mmu set 001c0000, pos 001c0000 1162 mmu set 001d0000, pos 001d0000 1162 mmu set 001e0000, pos 001e0000 1162 mmu set 001f0000, pos 001f0000 1162 mmu seets Jun 8 2016 00:22:57
rst:0x10 (RTCWDT_RTC_RESET),boot:0x1f (SPI_FAST_FLASH_BOOT) configsip: 156795334, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:4584 load:0x40078000,len:0 ho 12 tail 0 room 4 load:0x40078000,len:13184 entry 0x40078d38 Guru Meditation Error: Core 0 panic'ed (IllegalInstruction) . Exception was unhandled. Core 0 register dump: PC : 0x400e05d4 PS : 0x00060530 A0 : 0x800ddf7f A1 : 0x3ffe3bd0 0x400e05d4: heap_bubble_down at /Users/casner/src/github/esp-idf/components/log/./log.c:299
A2 : 0x00000001 A3 : 0x00000001 A4 : 0x88000070 A5 : 0x3ff133fc A6 : 0x3ff00044 A7 : 0x00000080 A8 : 0x80084330 A9 : 0x3ff49050 A10 : 0x3ffe3bd0 A11 : 0x000000e1 A12 : 0x0ffd114c A13 : 0x00000000 A14 : 0x000008ff A15 : 0x00000001 SAR : 0x00000017 EXCCAUSE: 0x00000000 EXCVADDR: 0x00000000 LBEG : 0x40098a6c LEND : 0x40098a77 LCOUNT : 0x00000000
Backtrace: 0x400e05d4:0x3ffe3bd0 0x400ddf7c:0x3ffe3c00 0x40081602:0x3ffe3c20 0x40078aca:0x3ffe3c40 0x40078b7d:0x3ffe3c70 0x40078d11:0x3ffe3cb0 0x40078e5a:0x3ffe3e70 0x40007c31:0x3ffe3eb0 0x4000073d:0x3ffe3f20 0x400e05d4: heap_bubble_down at /Users/casner/src/github/esp-idf/components/log/./log.c:299
0x400ddf7c: heap_caps_check_integrity_all at /Users/casner/src/github/esp-idf/components/heap/./heap_caps.c:409
0x40081602: timer_insert at /Users/casner/src/github/esp-idf/components/esp32/./esp_timer.c:400
Rebooting... ets Jun 8 2016 00:22:57 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Well, I'm at a loss now. I've backed up to the last commit I made (0c365d749de51481b6c9156ed705209631d35466) and the corresponding mongoose (ef2e519d6926480260029dfbdae20c7464240f6a) and did a clean build but the illegal instruction reboot loop still happens when I flash from USB. Does that ensure that the boot happens from the factory partition? That is, is it possible that the 3.1.005 flash to ota0 is still being used? Any other hints? -- Steve On Tue, 1 May 2018, Stephen Casner wrote:
The continuing saga... No, this illegal instruction reboot loop is _not_ a consequence of the 3.1.005 ovms3.bin file being inappropriate for my v3.0 hardware. When I "git pull" and build with my own sdkconfig as before I get the same result. I'll try going back to an earlier commit to verify if some code change caused this behavior.
-- Steve
On Tue, 1 May 2018, Stephen Casner wrote:
On Tue, 1 May 2018, Stephen Casner wrote:
On Tue, 1 May 2018, Mark Webb-Johnson wrote:
OK. v3.1.005 is built and out (in both edge and main).
While running 3.1.003, I just did flash from web, letting it default to the latest release. What I got was another copy of 3.1.003, not 3.1.005.
Oh, perhaps this result was because I have a v3.0 hardware module rather than v3.1? My second attempt was to go to the api.openvehicles.com/node/211 announcement of the v3.1.005 update and clicked on the "Latest Firmware" link. When I put the ovms3.bin file on my SD card and inserted it the software failed to boot up all the way, continuously looping to produce the output attached below.
-- Steve
rst:0xc (SW_CPU_RESET),boot:0x1f (SPI_FAST_FLASH_BOOT) configsip: 156795334, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:4584 load:0x40078000,len:0 ho 12 tail 0 room 4 load:0x40078000,len:13184 entry 0x40078d38 Guru Meditation Error: Core 0 panic'ed (IllegalInstruction) . Exception was unhandled. Core 0 register dump: PC : 0x400e05d4 PS : 0x00060530 A0 : 0x800ddf7f A1 : 0x3ffe3bd0 0x400e05d4: heap_bubble_down at /Users/casner/src/github/esp-idf/components/log/./log.c:299
A2 : 0x00000001 A3 : 0x00000001 A4 : 0x88000070 A5 : 0x3ff133fc A6 : 0x3ff00044 A7 : 0x00000080 A8 : 0x80084330 A9 : 0x3ff49050 A10 : 0x3ffe3bd0 A11 : 0x000000e1 A12 : 0x0ffd114c A13 : 0x00000000 A14 : 0x000000ff A15 : 0x00000001 SAR : 0x00000017 EXCCAUSE: 0x00000000 EXCVADDR: 0x00000000 LBEG : 0x40098a6c LEND : 0x40098a77 LCOUNT : 0x00000000
Backtrace: 0x400e05d4:0x3ffe3bd0 0x400ddf7c:0x3ffe3c00 0x40081602:0x3ffe3c20 0x40078aca:0x3ffe3c40 0x40078b7d:0x3ffe3c70 0x40078d11:0x3ffe3cb0 0x40078e5a:0x3ffe3e70 0x40007c31:0x3ffe3eb0 0x4000073d:0x3ffe3f20 0x400e05d4: heap_bubble_down at /Users/casner/src/github/esp-idf/components/log/./log.c:299
0x400ddf7c: heap_caps_check_integrity_all at /Users/casner/src/github/esp-idf/components/heap/./heap_caps.c:409
0x40081602: timer_insert at /Users/casner/src/github/esp-idf/components/esp32/./esp_timer.c:400
Rebooting... ets Jun 8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x1f (SPI_FAST_FLASH_BOOT) configsip: 156795334, SPIWP:0x00 clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0008,len:8 load:0x3fff1150,len:3472 load:0x4147c154,len:273751932 1162 mmu set 00010000, pos 00010000 1162 mmu set 00020000, pos 00020000 1162 mmu set 00030000, pos 00030000 1162 mmu set 00040000, pos 00040000 1162 mmu set 00050000, pos 00050000 1162 mmu set 00060000, pos 00060000 1162 mmu set 00070000, pos 00070000 1162 mmu set 00080000, pos 00080000 1162 mmu set 00090000, pos 00090000 1162 mmu set 000a0000, pos 000a0000 1162 mmu set 000b0000, pos 000b0000 1162 mmu set 000c0000, pos 000c0000 1162 mmu set 000d0000, pos 000d0000 1162 mmu set 000e0000, pos 000e0000 1162 mmu set 000f0000, pos 000f0000 1162 mmu set 00100000, pos 00100000 1162 mmu set 00110000, pos 00110000 1162 mmu set 00120000, pos 00120000 1162 mmu set 00130000, pos 00130000 1162 mmu set 00140000, pos 00140000 1162 mmu set 00150000, pos 00150000 1162 mmu set 00160000, pos 00160000 1162 mmu set 00170000, pos 00170000 1162 mmu set 00180000, pos 00180000 1162 mmu set 00190000, pos 00190000 1162 mmu set 001a0000, pos 001a0000 1162 mmu set 001b0000, pos 001b0000 1162 mmu set 001c0000, pos 001c0000 1162 mmu set 001d0000, pos 001d0000 1162 mmu set 001e0000, pos 001e0000 1162 mmu set 001f0000, pos 001f0000 1162 mmu seets Jun 8 2016 00:22:57
rst:0x10 (RTCWDT_RTC_RESET),boot:0x1f (SPI_FAST_FLASH_BOOT) configsip: 156795334, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:4584 load:0x40078000,len:0 ho 12 tail 0 room 4 load:0x40078000,len:13184 entry 0x40078d38 Guru Meditation Error: Core 0 panic'ed (IllegalInstruction) . Exception was unhandled. Core 0 register dump: PC : 0x400e05d4 PS : 0x00060530 A0 : 0x800ddf7f A1 : 0x3ffe3bd0 0x400e05d4: heap_bubble_down at /Users/casner/src/github/esp-idf/components/log/./log.c:299
A2 : 0x00000001 A3 : 0x00000001 A4 : 0x88000070 A5 : 0x3ff133fc A6 : 0x3ff00044 A7 : 0x00000080 A8 : 0x80084330 A9 : 0x3ff49050 A10 : 0x3ffe3bd0 A11 : 0x000000e1 A12 : 0x0ffd114c A13 : 0x00000000 A14 : 0x000008ff A15 : 0x00000001 SAR : 0x00000017 EXCCAUSE: 0x00000000 EXCVADDR: 0x00000000 LBEG : 0x40098a6c LEND : 0x40098a77 LCOUNT : 0x00000000
Backtrace: 0x400e05d4:0x3ffe3bd0 0x400ddf7c:0x3ffe3c00 0x40081602:0x3ffe3c20 0x40078aca:0x3ffe3c40 0x40078b7d:0x3ffe3c70 0x40078d11:0x3ffe3cb0 0x40078e5a:0x3ffe3e70 0x40007c31:0x3ffe3eb0 0x4000073d:0x3ffe3f20 0x400e05d4: heap_bubble_down at /Users/casner/src/github/esp-idf/components/log/./log.c:299
0x400ddf7c: heap_caps_check_integrity_all at /Users/casner/src/github/esp-idf/components/heap/./heap_caps.c:409
0x40081602: timer_insert at /Users/casner/src/github/esp-idf/components/esp32/./esp_timer.c:400
Rebooting... ets Jun 8 2016 00:22:57 _______________________________________________ OvmsDev mailing list 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
Steve, I only built the OTA for v3.1 hardware. Do you think we need it for v3.0 ongoing? I assumed developers would build their own. I think you’ve OTA updated the v3.1 firmware onto v3.0 hardware, and that is causing your issue. The ‘make flash’ command will flash the factory partition, but it won’t switch the currently active boot partition to factory. I found this in the mailing list archive: Supposedly if the OTA partition doesn’t boot (or checksum mismatch, etc), the bootloader will boot factory. The selection of current boot partition is in the otadata partition: # OVMS 16MB flash ESP32 Partition Table # Name, Type, SubType, Offset, Size nvs, data, nvs, 0x9000, 0x4000 otadata, data, ota, 0xd000, 0x2000 phy_init, data, phy, 0xf000, 0x1000 factory, app, factory, 0x10000, 4M ota_0, app, ota_0, , 4M ota_1, app, ota_1, , 4M store, data, fat, , 1M I guess zapping that would reset to defaults (factory boot)? I think erase_region may do that: esptool.py erase_region 0xd000 0x2000 But, haven’t tried it myself. Can you try it, and let us know? Regards, Mark.
On 2 May 2018, at 5:47 AM, Stephen Casner <casner@acm.org> wrote:
Well, I'm at a loss now. I've backed up to the last commit I made (0c365d749de51481b6c9156ed705209631d35466) and the corresponding mongoose (ef2e519d6926480260029dfbdae20c7464240f6a) and did a clean build but the illegal instruction reboot loop still happens when I flash from USB. Does that ensure that the boot happens from the factory partition? That is, is it possible that the 3.1.005 flash to ota0 is still being used? Any other hints?
-- Steve
On Tue, 1 May 2018, Stephen Casner wrote:
The continuing saga... No, this illegal instruction reboot loop is _not_ a consequence of the 3.1.005 ovms3.bin file being inappropriate for my v3.0 hardware. When I "git pull" and build with my own sdkconfig as before I get the same result. I'll try going back to an earlier commit to verify if some code change caused this behavior.
-- Steve
On Tue, 1 May 2018, Stephen Casner wrote:
On Tue, 1 May 2018, Stephen Casner wrote:
On Tue, 1 May 2018, Mark Webb-Johnson wrote:
OK. v3.1.005 is built and out (in both edge and main).
While running 3.1.003, I just did flash from web, letting it default to the latest release. What I got was another copy of 3.1.003, not 3.1.005.
Oh, perhaps this result was because I have a v3.0 hardware module rather than v3.1? My second attempt was to go to the api.openvehicles.com/node/211 announcement of the v3.1.005 update and clicked on the "Latest Firmware" link. When I put the ovms3.bin file on my SD card and inserted it the software failed to boot up all the way, continuously looping to produce the output attached below.
-- Steve
rst:0xc (SW_CPU_RESET),boot:0x1f (SPI_FAST_FLASH_BOOT) configsip: 156795334, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:4584 load:0x40078000,len:0 ho 12 tail 0 room 4 load:0x40078000,len:13184 entry 0x40078d38 Guru Meditation Error: Core 0 panic'ed (IllegalInstruction) . Exception was unhandled. Core 0 register dump: PC : 0x400e05d4 PS : 0x00060530 A0 : 0x800ddf7f A1 : 0x3ffe3bd0 0x400e05d4: heap_bubble_down at /Users/casner/src/github/esp-idf/components/log/./log.c:299
A2 : 0x00000001 A3 : 0x00000001 A4 : 0x88000070 A5 : 0x3ff133fc A6 : 0x3ff00044 A7 : 0x00000080 A8 : 0x80084330 A9 : 0x3ff49050 A10 : 0x3ffe3bd0 A11 : 0x000000e1 A12 : 0x0ffd114c A13 : 0x00000000 A14 : 0x000000ff A15 : 0x00000001 SAR : 0x00000017 EXCCAUSE: 0x00000000 EXCVADDR: 0x00000000 LBEG : 0x40098a6c LEND : 0x40098a77 LCOUNT : 0x00000000
Backtrace: 0x400e05d4:0x3ffe3bd0 0x400ddf7c:0x3ffe3c00 0x40081602:0x3ffe3c20 0x40078aca:0x3ffe3c40 0x40078b7d:0x3ffe3c70 0x40078d11:0x3ffe3cb0 0x40078e5a:0x3ffe3e70 0x40007c31:0x3ffe3eb0 0x4000073d:0x3ffe3f20 0x400e05d4: heap_bubble_down at /Users/casner/src/github/esp-idf/components/log/./log.c:299
0x400ddf7c: heap_caps_check_integrity_all at /Users/casner/src/github/esp-idf/components/heap/./heap_caps.c:409
0x40081602: timer_insert at /Users/casner/src/github/esp-idf/components/esp32/./esp_timer.c:400
Rebooting... ets Jun 8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x1f (SPI_FAST_FLASH_BOOT) configsip: 156795334, SPIWP:0x00 clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0008,len:8 load:0x3fff1150,len:3472 load:0x4147c154,len:273751932 1162 mmu set 00010000, pos 00010000 1162 mmu set 00020000, pos 00020000 1162 mmu set 00030000, pos 00030000 1162 mmu set 00040000, pos 00040000 1162 mmu set 00050000, pos 00050000 1162 mmu set 00060000, pos 00060000 1162 mmu set 00070000, pos 00070000 1162 mmu set 00080000, pos 00080000 1162 mmu set 00090000, pos 00090000 1162 mmu set 000a0000, pos 000a0000 1162 mmu set 000b0000, pos 000b0000 1162 mmu set 000c0000, pos 000c0000 1162 mmu set 000d0000, pos 000d0000 1162 mmu set 000e0000, pos 000e0000 1162 mmu set 000f0000, pos 000f0000 1162 mmu set 00100000, pos 00100000 1162 mmu set 00110000, pos 00110000 1162 mmu set 00120000, pos 00120000 1162 mmu set 00130000, pos 00130000 1162 mmu set 00140000, pos 00140000 1162 mmu set 00150000, pos 00150000 1162 mmu set 00160000, pos 00160000 1162 mmu set 00170000, pos 00170000 1162 mmu set 00180000, pos 00180000 1162 mmu set 00190000, pos 00190000 1162 mmu set 001a0000, pos 001a0000 1162 mmu set 001b0000, pos 001b0000 1162 mmu set 001c0000, pos 001c0000 1162 mmu set 001d0000, pos 001d0000 1162 mmu set 001e0000, pos 001e0000 1162 mmu set 001f0000, pos 001f0000 1162 mmu seets Jun 8 2016 00:22:57
rst:0x10 (RTCWDT_RTC_RESET),boot:0x1f (SPI_FAST_FLASH_BOOT) configsip: 156795334, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:4584 load:0x40078000,len:0 ho 12 tail 0 room 4 load:0x40078000,len:13184 entry 0x40078d38 Guru Meditation Error: Core 0 panic'ed (IllegalInstruction) . Exception was unhandled. Core 0 register dump: PC : 0x400e05d4 PS : 0x00060530 A0 : 0x800ddf7f A1 : 0x3ffe3bd0 0x400e05d4: heap_bubble_down at /Users/casner/src/github/esp-idf/components/log/./log.c:299
A2 : 0x00000001 A3 : 0x00000001 A4 : 0x88000070 A5 : 0x3ff133fc A6 : 0x3ff00044 A7 : 0x00000080 A8 : 0x80084330 A9 : 0x3ff49050 A10 : 0x3ffe3bd0 A11 : 0x000000e1 A12 : 0x0ffd114c A13 : 0x00000000 A14 : 0x000008ff A15 : 0x00000001 SAR : 0x00000017 EXCCAUSE: 0x00000000 EXCVADDR: 0x00000000 LBEG : 0x40098a6c LEND : 0x40098a77 LCOUNT : 0x00000000
Backtrace: 0x400e05d4:0x3ffe3bd0 0x400ddf7c:0x3ffe3c00 0x40081602:0x3ffe3c20 0x40078aca:0x3ffe3c40 0x40078b7d:0x3ffe3c70 0x40078d11:0x3ffe3cb0 0x40078e5a:0x3ffe3e70 0x40007c31:0x3ffe3eb0 0x4000073d:0x3ffe3f20 0x400e05d4: heap_bubble_down at /Users/casner/src/github/esp-idf/components/log/./log.c:299
0x400ddf7c: heap_caps_check_integrity_all at /Users/casner/src/github/esp-idf/components/heap/./heap_caps.c:409
0x40081602: timer_insert at /Users/casner/src/github/esp-idf/components/esp32/./esp_timer.c:400
Rebooting... ets Jun 8 2016 00:22:57 _______________________________________________ OvmsDev mailing list 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
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Mark,
I only built the OTA for v3.1 hardware. Do you think we need it for v3.0 ongoing? I assumed developers would build their own.
No. This was just a mistake by me not thinking clearly.
I think you’ve OTA updated the v3.1 firmware onto v3.0 hardware, and that is causing your issue. The ‘make flash’ command will flash the factory partition, but it won’t switch the currently active boot partition to factory.
Aha.
I found this in the mailing list archive:
Supposedly if the OTA partition doesn’t boot (or checksum mismatch, etc), the bootloader will boot factory.
The selection of current boot partition is in the otadata partition:
# OVMS 16MB flash ESP32 Partition Table # Name, Type, SubType, Offset, Size nvs, data, nvs, 0x9000, 0x4000 otadata, data, ota, 0xd000, 0x2000 phy_init, data, phy, 0xf000, 0x1000 factory, app, factory, 0x10000, 4M ota_0, app, ota_0, , 4M ota_1, app, ota_1, , 4M store, data, fat, , 1M
I guess zapping that would reset to defaults (factory boot)? I think erase_region may do that:
esptool.py erase_region 0xd000 0x2000
I decided to zap the ota_0 partition instead: $IDF_PATH/components/esptool_py/esptool/esptool.py erase_region 0x410000 0x400000 I had to "sudo ln -s /dev/tty.SLAB_USBtoUART /dev/ttyUSB0" first for this to work. This did let the factory partition boot. -- Steve
Not really sure why Espressif ‘make flash’ doesn’t switch OTA partition back to factory. That would seem to be a sensible approach. Good to hear it is back. There is also ‘make erase_flash’, but that is a bit drastic. Regards, Mark.
On 2 May 2018, at 8:32 AM, Stephen Casner <casner@acm.org> wrote:
Mark,
I only built the OTA for v3.1 hardware. Do you think we need it for v3.0 ongoing? I assumed developers would build their own.
No. This was just a mistake by me not thinking clearly.
I think you’ve OTA updated the v3.1 firmware onto v3.0 hardware, and that is causing your issue. The ‘make flash’ command will flash the factory partition, but it won’t switch the currently active boot partition to factory.
Aha.
I found this in the mailing list archive:
Supposedly if the OTA partition doesn’t boot (or checksum mismatch, etc), the bootloader will boot factory.
The selection of current boot partition is in the otadata partition:
# OVMS 16MB flash ESP32 Partition Table # Name, Type, SubType, Offset, Size nvs, data, nvs, 0x9000, 0x4000 otadata, data, ota, 0xd000, 0x2000 phy_init, data, phy, 0xf000, 0x1000 factory, app, factory, 0x10000, 4M ota_0, app, ota_0, , 4M ota_1, app, ota_1, , 4M store, data, fat, , 1M
I guess zapping that would reset to defaults (factory boot)? I think erase_region may do that:
esptool.py erase_region 0xd000 0x2000
I decided to zap the ota_0 partition instead:
$IDF_PATH/components/esptool_py/esptool/esptool.py erase_region 0x410000 0x400000
I had to "sudo ln -s /dev/tty.SLAB_USBtoUART /dev/ttyUSB0" first for this to work. This did let the factory partition boot.
-- Steve_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
On Tue, 1 May 2018, Michael Balzer wrote:
The crash reports I got are RAM related. I don't know yet how this can still happen, one was a failed "new" operator in server_v2 for the message encryption, the other a failed mongoose buffer resize. Both modules should have plenty of free RAM now in about any situation, so I'm a bit clueless about these.
Did this mongoose buffer problem occur on an ssh connection? It is still possible to use up a 4MB of RAM on a command that is generating output without being dependent on some source timing. For example, I expect that the "test chargen" command can still gobble up all the memory. It won't crash, though, because I added the error status plumbing necessary to avoid it and a check for the error in test_chargen. If you want to test with with the v3.1 module, I suggest unmounting the SD card first in case you need to reboot ungracefully, then try: test chargen 1000000 What I expect to happen is that a few hundred lines of output will be printed and then an error message will be logged on the async console, followed some time later by messages on the ssh console and the async console about characters lost. -- Steve
Steve, no, both problems occurred in server v2 transmissions, with no SSH connections active. Not sure about active webserver connections. I took care to use chunked transfers with small buffers in there, but if multiple commands are fired in parallel, each takes its own stack. The normal web UI does not do that though. Regards, Michael Am 01.05.2018 um 21:32 schrieb Stephen Casner:
On Tue, 1 May 2018, Michael Balzer wrote:
The crash reports I got are RAM related. I don't know yet how this can still happen, one was a failed "new" operator in server_v2 for the message encryption, the other a failed mongoose buffer resize. Both modules should have plenty of free RAM now in about any situation, so I'm a bit clueless about these. Did this mongoose buffer problem occur on an ssh connection? It is still possible to use up a 4MB of RAM on a command that is generating output without being dependent on some source timing. For example, I expect that the "test chargen" command can still gobble up all the memory. It won't crash, though, because I added the error status plumbing necessary to avoid it and a check for the error in test_chargen.
If you want to test with with the v3.1 module, I suggest unmounting the SD card first in case you need to reboot ungracefully, then try:
test chargen 1000000
What I expect to happen is that a few hundred lines of output will be printed and then an error message will be logged on the async console, followed some time later by messages on the ssh console and the async console about characters lost.
-- Steve _______________________________________________ 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 (4)
-
Geir Øyvind Vælidalo -
Mark Webb-Johnson -
Michael Balzer -
Stephen Casner