[Ovmsdev] ota questions

Fri Mar 16 09:28:03 HKT 2018

> The problem really seemed to occur only after switching from Wifi to modem, also tried with another SIM.

Yes, that is it. If modem gives you some public DNS, then you start wifi which gives a private DNS, then you stop wifi and are left with a modem that can’t access the wifi’s private DNS.

Setting 8.8.8.8 8.8.4.4, with my new code, avoids that.

> Another OTA issue, I haven't fully figured out yet: after switching on the modem, the download will always go via modem. As long as Wifi is available, it should be used -- maybe we also need to control the default route?

I haven’t address the ‘preferred route’ issue yet. My original idea was to sleep the modem when wifi came up, but I’m now thinking maybe better to keep the modem alive and instead use a priority preference thing. Something like some helper functions in NetManager that can be simply called to bind an outgoing connection to the highest priority network. But, not implemented yet.

Regards, Mark.

> On 16 Mar 2018, at 7:05 AM, Michael Balzer <dexter at expeedo.de> wrote:
> 
> The problem really seemed to occur only after switching from Wifi to modem, also tried with another SIM.
> 
> I have now configured the Google DNS servers as well, will report if I get the issue again.
> 
> Another OTA issue, I haven't fully figured out yet: after switching on the modem, the download will always go via modem. As long as Wifi is available, it should be used -- maybe we also need to control the default route?
> 
> OTA modem download does not work from my server. First thought it's Hologram (a single firmware update needs more volume than is covered by the free developer plan), but it also does not work with my local SIM with a high volume plan.
> 
> I noticed a rather strange effect: when I let it run, the server actually logged the download after 17 minutes, but still no download progress on the console.
> 
> I need to retry this with verbose logging on the gsm-ppp channel to see what's going on.
> 
> Regards,
> Michael
> 
> 
> Am 12.03.2018 um 16:08 schrieb Mark Webb-Johnson:
>> I’ve added a ‘network status’ command. Can you try it, when you get DNS errors, to see what the DNS servers are set to?
>> 
>> Regards, Mark
>> 
>>> On 12 Mar 2018, at 10:29 AM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>>> 
>>>> Working on the OTA web UI.
>>> 
>>> That will be very useful. Thanks.
>>> 
>>>> a) Flashing and changing the boot partition outputs some irritating overflow and "??" log messages:
>>> 
>>>> Can these safely be ignored? The flashed partitions seem to work correctly.
>>> 
>>> Yes, I too find these ugly. It is a ‘make monitor weirdism:
>>> 
>>> https://www.esp32.com/viewtopic.php?t=4199 <https://www.esp32.com/viewtopic.php?t=4199>
>>> 
>>> No, no need to worry. Those are from the ``make monitor`` command. As soon as this sees a hex number scroll by that smells like an address in the ESP32 memory map, it tries to be helpful and converts it to a symbol. In some cases, this leads it to weird messages like this.
>>> 
>>>> b) How do you get back to the factory partition if something went so wrong you can't use the "ota" command?
>>> 
>>> 
>>> 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.
>>> 
>>>> c) ota flash http still gives me a DNS lookup error on any other host than api.openvehicles.com <http://api.openvehicles.com/> and fails to download from api.openvehicles.com <http://api.openvehicles.com/>, regardless of
>>>> the type of network (wifi/modem).
>>> 
>>> 
>>> I saw this a few months ago, but not recently.
>>> 
>>> Line 107 of ovms_net.cpp. It just does a getaddrinfo() on the host.
>>> 
>>> Regards, Mark.
>>> 
>>>> On 12 Mar 2018, at 7:13 AM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>>> 
>>>> Working on the OTA web UI.
>>>> 
>>>> Some questions:
>>>> 
>>>> a) Flashing and changing the boot partition outputs some irritating overflow and "??" log messages:
>>>> 
>>>> OVMS > ota flash vfs /sd/ovms3.done
>>>> Current running partition is: ota_0
>>>> Target partition is: ota_1
>>>> Source image is 1480592 bytes in size
>>>> Preparing flash partition...
>>>> Flashing image partition...
>>>> Setting boot partition...
>>>> OTA flash was successful
>>>>   Flashed 1480592 bytes from /sd/ovms3.done
>>>>   Next boot will be from 'ota_1'
>>>> I (1316956) esp_image: segment 0: paddr=0x00810020 vaddr=0x3f400020 size=0x5879c (362396) map
>>>> I (1317156) esp_image: segment 1: paddr=0x008687c4 vaddr=0x3ffb0000 size=0x0382c ( 14380)
>>>> I (1317156) esp_image: segment 2: paddr=0x0086bff8 vaddr=0x40080000 size=0x00400 (  1024)
>>>> 0x40080000: _WindowOverflow4 at /home/balzer/esp/esp-idf/components/freertos/./xtensa_vectors.S:1685
>>>> 
>>>> I (1317166) esp_image: segment 3: paddr=0x0086c400 vaddr=0x40080400 size=0x03c10 ( 15376)
>>>> I (1317176) esp_image: segment 4: paddr=0x00870018 vaddr=0x400d0018 size=0xfb154 (1028436) map
>>>> 0x400d0018: _flash_cache_start at ??:?
>>>> 
>>>> I (1317746) esp_image: segment 5: paddr=0x0096b174 vaddr=0x40084010 size=0x0e5b4 ( 58804)
>>>> 0x40084010: spi_flash_mmap at /home/balzer/esp/esp-idf/components/spi_flash/./flash_mmap.c:293
>>>> 
>>>> I (1317776) esp_image: segment 6: paddr=0x00979730 vaddr=0x400c0000 size=0x00034 (    52)
>>>> I (1317776) esp_image: segment 0: paddr=0x00810020 vaddr=0x3f400020 size=0x5879c (362396) map
>>>> I (1317976) esp_image: segment 1: paddr=0x008687c4 vaddr=0x3ffb0000 size=0x0382c ( 14380)
>>>> I (1317986) esp_image: segment 2: paddr=0x0086bff8 vaddr=0x40080000 size=0x00400 (  1024)
>>>> 0x40080000: _WindowOverflow4 at /home/balzer/esp/esp-idf/components/freertos/./xtensa_vectors.S:1685
>>>> 
>>>> I (1317986) esp_image: segment 3: paddr=0x0086c400 vaddr=0x40080400 size=0x03c10 ( 15376)
>>>> I (1317996) esp_image: segment 4: paddr=0x00870018 vaddr=0x400d0018 size=0xfb154 (1028436) map
>>>> 0x400d0018: _flash_cache_start at ??:?
>>>> 
>>>> I (1318566) esp_image: segment 5: paddr=0x0096b174 vaddr=0x40084010 size=0x0e5b4 ( 58804)
>>>> 0x40084010: spi_flash_mmap at /home/balzer/esp/esp-idf/components/spi_flash/./flash_mmap.c:293
>>>> 
>>>> I (1318606) esp_image: segment 6: paddr=0x00979730 vaddr=0x400c0000 size=0x00034 (    52)
>>>> 
>>>> …
>>>> 
>>>> OVMS > ota boot ota_1
>>>> Boot from ota_1 at 0x00810000 (size 0x00400000)
>>>> I (301766) esp_image: segment 0: paddr=0x00810020 vaddr=0x3f400020 size=0x5879c (362396) map
>>>> I (301966) esp_image: segment 1: paddr=0x008687c4 vaddr=0x3ffb0000 size=0x0382c ( 14380)
>>>> I (301976) esp_image: segment 2: paddr=0x0086bff8 vaddr=0x40080000 size=0x00400 (  1024)
>>>> 0x40080000: _WindowOverflow4 at /home/balzer/esp/esp-idf/components/freertos/./xtensa_vectors.S:1685
>>>> 
>>>> I (301976) esp_image: segment 3: paddr=0x0086c400 vaddr=0x40080400 size=0x03c10 ( 15376)
>>>> I (301986) esp_image: segment 4: paddr=0x00870018 vaddr=0x400d0018 size=0xfb154 (1028436) map
>>>> 0x400d0018: _flash_cache_start at ??:?
>>>> 
>>>> I (302556) esp_image: segment 5: paddr=0x0096b174 vaddr=0x40084010 size=0x0e5b4 ( 58804)
>>>> 0x40084010: spi_flash_mmap at /home/balzer/esp/esp-idf/components/spi_flash/./flash_mmap.c:293
>>>> 
>>>> I (302596) esp_image: segment 6: paddr=0x00979730 vaddr=0x400c0000 size=0x00034 (    52)
>>>> 
>>>> 
>>>> Can these safely be ignored? The flashed partitions seem to work correctly.
>>>> 
>>>> 
>>>> b) How do you get back to the factory partition if something went so wrong you can't use the "ota" command?
>>>> 
>>>> I would have expected "make flash" to reset the boot partition to "factory", as all flashes are only done there, but it doesn't.
>>>> 
>>>> So if you're on another partition with a broken firmware, how do you recover? Is there a way to set the boot partition using esptool.py?
>>>> 
>>>> 
>>>> c) ota flash http still gives me a DNS lookup error on any other host than api.openvehicles.com <http://api.openvehicles.com/> and fails to download from api.openvehicles.com <http://api.openvehicles.com/>, regardless of
>>>> the type of network (wifi/modem).
>>>> 
>>>> OVMS > ota flash http www.google.com/ovms3.bin <http://www.google.com/ovms3.bin>
>>>> Current running partition is: factory
>>>> Target partition is: ota_0
>>>> Download firmware from www.google.com/ovms3.bin <http://www.google.com/ovms3.bin> to ota_0
>>>> Error: Request failed
>>>> W (666891) net: DNS lookup on www.google.com <http://www.google.com/> failed err=200
>>>> 
>>>> OVMS > ota flash http api.openvehicles.com/test.bin <http://api.openvehicles.com/test.bin>
>>>> Current running partition is: factory
>>>> Target partition is: ota_0
>>>> Download firmware from api.openvehicles.com/test.bin <http://api.openvehicles.com/test.bin> to ota_0
>>>> […dead, needs reset]
>>>> 
>>>> Is this a local problem of mine?
>>>> 
>>>> 
>>>> 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.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/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.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180316/6b1977a9/attachment.htm>