[Ovmsdev] esp-idf v3.3
Michael Balzer
dexter at expeedo.de
Sat Jul 27 00:02:27 HKT 2019
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 at heuer-humfeld.de <mailto:egon at heuer-humfeld.de>> <egon at heuer-humfeld.de <mailto:egon at 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 at lists.openvehicles.com <mailto:ovmsdev-bounces at lists.openvehicles.com>> *Im Auftrag von *Mark Webb-Johnson
>> *Gesendet:* Montag, 22. Juli 2019 15:06
>> *An:* OVMS Developers <ovmsdev at lists.openvehicles.com <mailto:ovmsdev at 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 at expeedo.de <mailto:dexter at 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 at expeedo.de <mailto:dexter at 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 at expeedo.de <mailto:dexter at 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 at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20190726/a59a91ee/attachment.htm>
More information about the OvmsDev
mailing list