[Ovmsdev] for-v3.3: ota flash http crashes
Mark Webb-Johnson
mark at webb-johnson.net
Tue Nov 23 19:33:47 HKT 2021
Yes, a good idea. The other OTA, or the factory, partition should work.
P.S. The new logic seems to work for my rev3 test boards
OVMS# ota flash http
Current running partition is: factory
Target partition is: ota_0
Download firmware from api.openvehicles.com/firmware/ota/v3.3/main/ovms3.bin to ota_0
Expected file size is 3309600
Regards, Mark
> On 23 Nov 2021, at 3:00 PM, Michael Balzer <dexter at expeedo.de> wrote:
>
> Thanks Mark,
>
> fix confirmed.
>
> Who ran into the issue already may also be able to switch back to the previous 3.2 boot partition, do a reboot and then update again from there.
>
> Regards,
> Michael
>
>
> Am 23.11.21 um 03:22 schrieb Mark Webb-Johnson:
>> I have merged in these reverts, and committed, then built a new edge on my server. I ran a few OTA updates with this, and it seems ok.
>>
>> The code now uses the old ovms_http library, based on normal sockets (not mongoose). This should also workaround the ‘ota flash http’ issue we had with ssh client connections. I would prefer to use mongoose (apart from uniformity, this also gave us support for HTTPS), but it is quite tricky to do this in a blocking way with the ssh client also over mongoose. Would need to re-work to be non-blocking for these commands.
>>
>> Sorry, but existing edge users will probably have to re-flash from SD card or USB.
>>
>> Regards, Mark.
>>
>>> On 23 Nov 2021, at 8:24 AM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>>>
>>> Signed PGP part
>>> Damn. I had made the change to roll that back, but forgot to merge my local branch with those changes.
>>>
>>> I just tried, but got some conflicts. I’ll fix those up, and then commit again.
>>>
>>> Regards, Mark.
>>>
>>>> On 23 Nov 2021, at 1:58 AM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>>>
>>>> Signed PGP part
>>>> Mark,
>>>>
>>>> since updating to 3.3.001 my test module again crashes on any ota update attempt.
>>>>
>>>> The signature is the same as below, and the code seems to be unchanged…?
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>>
>>>> Am 17.09.21 um 10:48 schrieb Mark Webb-Johnson:
>>>>> I’ll have a look at it over the weekend.
>>>>>
>>>>> Regards, Mark.
>>>>>
>>>>>> On 17 Sep 2021, at 4:39 PM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>>>>>
>>>>>> Signed PGP part
>>>>>> There is another fatal issue with OvmsSyncHttpClient besides the issue with running in the mongoose context: OTA updates are no longer possible.
>>>>>>
>>>>>> When flashing via HTTP, the OvmsSyncHttpClient tries to allocate memory for a full firmware image, which of course fails:
>>>>>>
>>>>>> OVMS# ota flash http
>>>>>> Current running partition is: factory
>>>>>> Target partition is: ota_0
>>>>>> Download firmware from ovms.dexters-web.de/firmware/ota/v3.1/edge/ovms3.bin <http://ovms.dexters-web.de/firmware/ota/v3.1/edge/ovms3.bin> to ota_0
>>>>>> Guru Meditation Error: Core 1 panic'ed (StoreProhibited). Exception was unhandled.
>>>>>> Core 1 register dump:
>>>>>> PC : 0x4022438b PS : 0x00060a30 A0 : 0x802245cd A1 : 0x3ffe9c70
>>>>>> A2 : 0x00000000 A3 : 0x3ffe6f5c A4 : 0x00000001 A5 : 0xffffffff
>>>>>> A6 : 0x3fabad7c A7 : 0xff000000 A8 : 0x00000000 A9 : 0x3ffe9c50
>>>>>> A10 : 0x00000000 A11 : 0x3ffe6f5c A12 : 0x00000001 A13 : 0x0000000a
>>>>>> A14 : 0x00000037 A15 : 0x00000057 SAR : 0x00000018 EXCCAUSE: 0x0000001d
>>>>>> EXCVADDR: 0x00000000 LBEG : 0x4008b179 LEND : 0x4008b19b LCOUNT : 0xffffffff
>>>>>>
>>>>>> ELF file SHA256: 94a8e191baae33a5
>>>>>>
>>>>>> Backtrace: 0x4022438b:0x3ffe9c70 0x402245ca:0x3ffe9c90 0x40132f93:0x3ffe9cc0 0x40132e51:0x3ffe9d10 0x40133609:0x3ffe9d40 0x402e7472:0x3ffe9d70 0x4010e229:0x3ffe9d90 0x4010fbd5:0x3ffe9dd0 0x40110015:0x3ffe9e00 0x401102de:0x3ffe9e70 0x4010c51a:0x3ffe9ed0 0x400f5a4f:0x3ffe9ef0 0x400f5afd:0x3ffe9f40
>>>>>>
>>>>>> Rebooting...
>>>>>>
>>>>>>
>>>>>> 0x4022438b is in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_S_copy(char*, char const*, unsigned int) (/builds/idf/crosstool-NG/.build/xtensa-esp32-elf/build/build-cc-gcc-final/xtensa-esp32-elf/esp32-psram/libstdc++-v3/include/bits/char_traits.h:243).
>>>>>> 0x402245ca is in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::reserve(unsigned int) (/builds/idf/crosstool-NG/.build/xtensa-esp32-elf/build/build-cc-gcc-final/xtensa-esp32-elf/esp32-psram/libstdc++-v3/include/bits/basic_string.tcc:298).
>>>>>> 0x40132f93 is in OvmsSyncHttpClient::ConnectionHeaders(mg_connection*) (/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_http/src/ovms_http.cpp:381).
>>>>>> 376 else
>>>>>> 377 {
>>>>>> 378 if (header.compare(0,15,"Content-Length:") == 0)
>>>>>> 379 {
>>>>>> 380 m_bodysize = atoi(header.substr(15).c_str());
>>>>>> 381 m_body.reserve(m_bodysize+1);
>>>>>> 382 }
>>>>>> 383 else if (header.compare(0,5,"HTTP/") == 0)
>>>>>> 384 {
>>>>>> 385 size_t space = header.find(' ');
>>>>>> 0x40132e51 is in OvmsSyncHttpClient::ConnectionData(mg_connection*, unsigned char*, unsigned int) (/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_http/src/ovms_http.cpp:316).
>>>>>> 311 data += len;
>>>>>> 312 consumed += len;
>>>>>> 313 len = 0;
>>>>>> 314 }
>>>>>> 315
>>>>>> 316 ConnectionHeaders(nc);
>>>>>> 317 }
>>>>>> 318
>>>>>> 319 if (! m_inheaders)
>>>>>> 320 {
>>>>>> 0x40133609 is in OvmsSyncHttpClient::MongooseCallback(mg_connection*, int, void*) (/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_http/src/ovms_http.cpp:124).
>>>>>> 119 m_mgconn = NULL;
>>>>>> 120 }
>>>>>> 121 break;
>>>>>> 122
>>>>>> 123 case MG_EV_RECV:
>>>>>> 124 mbuf_remove(&nc->recv_mbuf, ConnectionData(nc,(uint8_t*)nc->recv_mbuf.buf, nc->recv_mbuf.len));
>>>>>> 125 break;
>>>>>> 126
>>>>>> 127 default:
>>>>>> 128 break;
>>>>>>
>>>>>>
>>>>>> Can we switch back to using the old async client?
>>>>>>
>>>>>> Regards,
>>>>>> Michael
>>>>>>
>>>>>> --
>>>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at 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 at lists.openvehicles.com <mailto:OvmsDev at 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 at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20211123/87a24be4/attachment-0001.htm>
More information about the OvmsDev
mailing list