[Ovmsdev] esp-idf v3.3

[Mark Webb-Johnson]

Michael,

Some comments / questions:

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?

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?

Regards, Mark.

> On 22 Jul 2019, at 3:04 PM, Michael Balzer <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
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20190722/9d003cfd/attachment.htm>