[Ovmsdev] esp-idf v3.3

Tue Jul 23 11:58:05 HKT 2019

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> <egon at 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 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 <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 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 <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 <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20190723/b6e4826a/attachment.htm>