Another thought - maybe the compiler version?

3.1 requires xtensa gcc 1.22.0-80 (g6c4433a-5.2.0).

https://esp-idf.readthedocs.io/en/latest/get-started/linux-setup.html

Regards, Mark.

On 16 Feb 2018, at 2:19 PM, Stephen Casner <casner@acm.org> wrote:

Mine says:

OVMS > metrics list m.version
m.version
3.0.0/factory/main build (idf v3.1-dev-212-g00fa3889-dirty) Feb  7 2018 22:10:10

But, truth be told, I'm currently compiing from my own fork of
espressif/esp-idf that I set up to issue a PR to espressif for my
changes that support the memory diagnostics.

                                                       -- Steve

On Thu, 15 Feb 2018, Greg D. wrote:

Ok.  Back to half-sanity.  rm -rf esp-idf, Refetched from master including submodule
stuff, rm -r build, make clean, make, make flash.  Compiles and runs.

But still shows wrong version for m.version, and /store is still a mess.  Not sure if
I care about the m.version; what is going on with vfs?

Back to the TV...

Greg


Stephen Casner wrote:

Right.

    -- Steve

On Thu, 15 Feb 2018, Greg D. wrote:

Ok, so master from the openvehicles clone?

Greg


Stephen Casner wrote:

Gre,

No, we left behind the v2.1 of esp-idf a while ago.  We're now on
master.

                                                       -- Steve

On Thu, 15 Feb 2018, Greg D. wrote:

Mmm, never mind...  I realize we're still based on v2.1, right?

I've re-fetched stuff from the 2.1 branch, and still have the same results.  v3.0.0
listed as m.version, and junk in /store.

Now what?

Greg


Greg D. wrote:
     Ok, this is odd...  Are you sure esp-idf v3.1 is actually on Github?
     Tried re-fetching everything, and found this:

           greg@linux-0rpb:~/esp> git clone
           https://github.com/openvehicles/esp-idf.git
           Cloning into 'esp-idf'...
           remote: Counting objects: 44182, done.
           remote: Compressing objects: 100% (8/8), done.
           remote: Total 44182 (delta 0), reused 1 (delta 0), pack-reused
           44174
           Receiving objects: 100% (44182/44182), 50.53 MiB | 11.75
           MiB/s, done.
           Resolving deltas: 100% (31074/31074), done.
           greg@linux-0rpb:~/esp> cd esp-idf
           greg@linux-0rpb:~/esp/esp-idf> git branch -a
           * master
             remotes/origin/HEAD -> origin/master
             remotes/origin/feature/psram_malloc
             remotes/origin/master
             remotes/origin/release/v2.0
             remotes/origin/release/v2.1
             remotes/origin/release/v3.0
           greg@linux-0rpb:~/esp/esp-idf>

     Shouldn't there be a v3.1 listed there too?  Last entry is 3.0.

     Anyway, the first question is whether we have one problem or two...  Is my
     problem with /store related to v3.0 vs v3.1, or is it a separate problem
     on its own?  Do I simply need to clear flash and reload my config?  If so,
     what is the best way?

     Greg


     Mark Webb-Johnson wrote:
     Nope. Old hardware.
Out of ideas. I thought it just picked up the git version.

Regards, Mark.

     On 15 Feb 2018, at 12:07 PM, Greg D. <gregd2350@gmail.com>
     wrote:

No difference.

Are you on the new hardware?

Greg


Mark Webb-Johnson wrote:
     In your ovms directory:
     make clean
rm -rf build
make flash


That’s all I can think of.

Regards, Mark

     On 15 Feb 2018, at 11:59 AM, Greg D.
     <gregd2350@gmail.com> wrote:

Yes, and yes.  The top entry exactly matches your log.

Greg


Mark Webb-Johnson wrote:
     And you’ve already ‘git pull’ and ‘git
     submodule update’ in that esp idf?
If you ‘git log’, you should get:

     commit
     8d8d62da9e58305c8f7f4792264f8cab3ffe104b
     (HEAD -> master, origin/master,
     origin/HEAD)
Merge: 5bf85d06 ca3faa61
Author: Mark Webb-Johnson
<mark@webb-johnson.net>
Date:   Tue Feb 13 13:27:55 2018 +0800

    Merge remote-tracking branch
'espressif/master'


(which is where the 8d8d62da comes from)

Regards, Mark.

     On 15 Feb 2018, at 11:42 AM, Greg D.
     <gregd2350@gmail.com> wrote:

Yes and yes.
     greg@linux-0rpb:~/esp/esp-idf>
     git branch -a
     * master
       remotes/origin/HEAD ->
     origin/master

     remotes/origin/feature/psram_malloc
       remotes/origin/master
       remotes/origin/release/v2.0
       remotes/origin/release/v2.1
       remotes/origin/release/v3.0
     greg@linux-0rpb:~/esp/esp-idf>
     git remote -v
     origin
     https://github.com/openvehicles/esp-idf.git
     (fetch)
     origin
     https://github.com/openvehicles/esp-idf.git
     (push)
     greg@linux-0rpb:~/esp/esp-idf>

Greg


Mark Webb-Johnson wrote:
     In your esp idf directory, can
     you check ‘git branch -a’. Make
     sure you are on ‘master’ branch.
     Also ‘git remote -v’. Make sure
     you are on openvehicles clone.
Mark


     On 15 Feb 2018, at 10:24
     AM, Greg D.
     <gregd2350@gmail.com>
     wrote:

Hi Mark,

So, I changed the
CONFIG_LWIP_SO_REUSE value and
did a make flash.  That
displayed another option,
default Yes, changed to no.
But, same result with /store.

One significant difference is
that you're on idf 3.1 and I'm
on 3.0...  (3.0.0/factory/main
build (idf
v3.0-dev-1781-g8d8d62da) Feb 14
2018 18:12:05)

Did I miss a cog on this?

Greg


Mark Webb-Johnson wrote:
     My store seems ok:
     OVMS > vfs ls
     /store
ovms_config
obd2ecu
play

OVMS > metrics list
m.version
m.version

 3.0.0/factory/main
build (idf
v3.1-dev-391-g8d8d62da)
Feb 13 2018 14:05:21


Anybody else seeing this
issue?

Regarding the
CONFIG_LWIP_SO_REUSE, in
menuconfig you can use ‘/‘
to search for it. The
parameter is in Component
Config / LWIP.

Regards, Mark.


_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev




_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev


_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev




_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev


_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev




_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev


_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev




_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev




_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev






_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev



_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev