[Ovmsdev] esp-idf v3.3

Tue Jul 23 01:48:25 HKT 2019

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> Im Auftrag von Mark Webb-Johnson
Gesendet: Montag, 22. Juli 2019 15:06
An: OVMS Developers <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

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