It's been several days since I've seen any messages on this list. I suppose that Mark has been occupied by the hardware changes. Myself, I've finished the things I was working on (with the possible exception of adding an immediate-send option back into Mongoose), but I've entered a PR to get the code I added to esp-idf to support the per-task heap allocation commands accepted into the mainline and have been refining the code in response to change requests. -- Steve
Yes, got a bit quiet. I'll be busy with a customer project for some more days. I've begun working on a websocket channel to push events & metrics updates etc. to the web console. Regards, Michael Am 11.02.2018 um 19:15 schrieb Stephen Casner:
It's been several days since I've seen any messages on this list. I suppose that Mark has been occupied by the hardware changes. Myself, I've finished the things I was working on (with the possible exception of adding an immediate-send option back into Mongoose), but I've entered a PR to get the code I added to esp-idf to support the per-task heap allocation commands accepted into the mainline and have been refining the code in response to change requests.
-- Steve _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
I’ve been busy... Back in Hong Kong now, and still working with China on hardware issues. We are close, but hard to make progress as most of the China factories have already shutdown. Currently waiting for samples of the 16MB WROVER modules (should arrive any day now) as our attempts to upgrade existing modules were hit-and-miss. We do have the Chinese New Year break coming up this weekend in HK. I hope to get some coding done then. Regards, Mark
On 12 Feb 2018, at 2:15 AM, Stephen Casner <casner@acm.org> wrote:
It's been several days since I've seen any messages on this list. I suppose that Mark has been occupied by the hardware changes. Myself, I've finished the things I was working on (with the possible exception of adding an immediate-send option back into Mongoose), but I've entered a PR to get the code I added to esp-idf to support the per-task heap allocation commands accepted into the mainline and have been refining the code in response to change requests.
-- Steve _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Steve, I’m seeing weird heap corruption when I do PSRAM enabled builds and have heap debugging enabled. When I turn off the heap debugging, everything runs fine. I notice this: https://github.com/espressif/esp-idf/issues/1582 <https://github.com/espressif/esp-idf/issues/1582> and some associated fixes by Espressif to master. Any issues with us merging in upstream Espress ESP IDF master to our clone? See if that resolves the problem? Regards, Mark.
On 12 Feb 2018, at 2:15 AM, Stephen Casner <casner@acm.org> wrote:
It's been several days since I've seen any messages on this list. I suppose that Mark has been occupied by the hardware changes. Myself, I've finished the things I was working on (with the possible exception of adding an immediate-send option back into Mongoose), but I've entered a PR to get the code I added to esp-idf to support the per-task heap allocation commands accepted into the mainline and have been refining the code in response to change requests.
-- Steve _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Mark, I think the merge you propose should work. As I mentioned, I'm in discussion with @projectgus to get my code merged into the mainline. -- Steve On Mon, 12 Feb 2018, Mark Webb-Johnson wrote:
Steve,
I’m seeing weird heap corruption when I do PSRAM enabled builds and have heap debugging enabled. When I turn off the heap debugging, everything runs fine.
I notice this:
https://github.com/espressif/esp-idf/issues/1582 <https://github.com/espressif/esp-idf/issues/1582>
and some associated fixes by Espressif to master.
Any issues with us merging in upstream Espress ESP IDF master to our clone? See if that resolves the problem?
Regards, Mark.
On 12 Feb 2018, at 2:15 AM, Stephen Casner <casner@acm.org> wrote:
It's been several days since I've seen any messages on this list. I suppose that Mark has been occupied by the hardware changes. Myself, I've finished the things I was working on (with the possible exception of adding an immediate-send option back into Mongoose), but I've entered a PR to get the code I added to esp-idf to support the per-task heap allocation commands accepted into the mainline and have been refining the code in response to change requests.
-- Steve _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I did the merge. Unfortunately, Espressif broke mDNS by changing the API, so I’ve also had to change OVMS v3 firmware to match. This means developers need to update both ESP IDF and OVMS v3 source trees, before mDNS will compile. cd ~/esp/esp-idf git pull git submodule update cd ~/ovms/vehicle/OVMS.V3 git pull make (changing paths as appropriate) Or just disable the OVMS mDNS component if you are not using it. It all compiles and seems to run for me now. There are a bunch of new configuration options. The only one I would like enabled (disabled by default) is CONFIG_LWIP_SO_REUSE=y. Regards, Mark.
On 12 Feb 2018, at 3:02 PM, Stephen Casner <casner@acm.org> wrote:
Mark,
I think the merge you propose should work. As I mentioned, I'm in discussion with @projectgus to get my code merged into the mainline.
-- Steve
On Mon, 12 Feb 2018, Mark Webb-Johnson wrote:
Steve,
I’m seeing weird heap corruption when I do PSRAM enabled builds and have heap debugging enabled. When I turn off the heap debugging, everything runs fine.
I notice this:
https://github.com/espressif/esp-idf/issues/1582 <https://github.com/espressif/esp-idf/issues/1582>
and some associated fixes by Espressif to master.
Any issues with us merging in upstream Espress ESP IDF master to our clone? See if that resolves the problem?
Regards, Mark.
On 12 Feb 2018, at 2:15 AM, Stephen Casner <casner@acm.org> wrote:
It's been several days since I've seen any messages on this list. I suppose that Mark has been occupied by the hardware changes. Myself, I've finished the things I was working on (with the possible exception of adding an immediate-send option back into Mongoose), but I've entered a PR to get the code I added to esp-idf to support the per-task heap allocation commands accepted into the mainline and have been refining the code in response to change requests.
-- Steve _______________________________________________ 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
Updated ok, but I find that my config has been reset. Poking around, I find that it /store seems to be whacked! OVMS > vfs ls /store ��������.��� ��������.��� ��������.��� ��������.��� ��������.��� ��������.��� ��������.��� ��������.��� ��������.��� ��������.��� ��������.��� ��������.��� <snip> ovms_config What happened? Also, I didn't see CONFIG_LWIP_SO_REUSE come up as a config item on the first make. Is this one I need to edit manually? Is that related to the above? Thanks, Greg Mark Webb-Johnson wrote: I did the merge. Unfortunately, Espressif broke mDNS by changing the API, so I’ve also had to change OVMS v3 firmware to match. This means developers need to update both ESP IDF and OVMS v3 source trees, before mDNS will compile. cd ~/esp/esp-idf git pull git submodule update cd ~/ovms/vehicle/OVMS.V3 git pull make (changing paths as appropriate) Or just disable the OVMS mDNS component if you are not using it. It all compiles and seems to run for me now. There are a bunch of new configuration options. The only one I would like enabled (disabled by default) is CONFIG_LWIP_SO_REUSE=y. Regards, Mark. On 12 Feb 2018, at 3:02 PM, Stephen Casner <casner@acm.org> wrote: Mark, I think the merge you propose should work. As I mentioned, I'm in discussion with @projectgus to get my code merged into the mainline. -- Steve On Mon, 12 Feb 2018, Mark Webb-Johnson wrote: Steve, I’m seeing weird heap corruption when I do PSRAM enabled builds and have heap debugging enabled. When I turn off the heap debugging, everything runs fine. I notice this: https://github.com/espressif/esp-idf/issues/1582 < https://github.com/espressif/esp-idf/issues/1582> and some associated fixes by Espressif to master. Any issues with us merging in upstream Espress ESP IDF master to our clone? See if that resolves the problem? Regards, Mark. On 12 Feb 2018, at 2:15 AM, Stephen Casner <casner@acm.org> wrote: It's been several days since I've seen any messages on this list. I suppose that Mark has been occupied by the hardware changes. Myself, I've finished the things I was working on (with the possible exception of adding an immediate-send option back into Mongoose), but I've entered a PR to get the code I added to esp-idf to support the per-task heap allocation commands accepted into the mainline and have been refining the code in response to change requests. -- Steve _______________________________________________ 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 listOvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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.
On 15 Feb 2018, at 4:25 AM, Greg D <gregd2350@gmail.com> wrote:
Updated ok, but I find that my config has been reset. Poking around, I find that it /store seems to be whacked!
OVMS > vfs ls /store ��������.��� ��������.��� ��������.��� ��������.��� ��������.��� ��������.��� ��������.��� ��������.��� ��������.��� ��������.��� ��������.��� ��������.��� <snip> ovms_config
What happened?
Also, I didn't see CONFIG_LWIP_SO_REUSE come up as a config item on the first make. Is this one I need to edit manually? Is that related to the above?
Thanks,
Greg
Mark Webb-Johnson wrote:
I did the merge. Unfortunately, Espressif broke mDNS by changing the API, so I’ve also had to change OVMS v3 firmware to match.
This means developers need to update both ESP IDF and OVMS v3 source trees, before mDNS will compile.
cd ~/esp/esp-idf git pull git submodule update
cd ~/ovms/vehicle/OVMS.V3 git pull make
(changing paths as appropriate)
Or just disable the OVMS mDNS component if you are not using it.
It all compiles and seems to run for me now. There are a bunch of new configuration options. The only one I would like enabled (disabled by default) is CONFIG_LWIP_SO_REUSE=y.
Regards, Mark.
On 12 Feb 2018, at 3:02 PM, Stephen Casner <casner@acm.org <mailto:casner@acm.org>> wrote:
Mark,
I think the merge you propose should work. As I mentioned, I'm in discussion with @projectgus to get my code merged into the mainline.
-- Steve
On Mon, 12 Feb 2018, Mark Webb-Johnson wrote:
Steve,
I’m seeing weird heap corruption when I do PSRAM enabled builds and have heap debugging enabled. When I turn off the heap debugging, everything runs fine.
I notice this:
https://github.com/espressif/esp-idf/issues/1582 <https://github.com/espressif/esp-idf/issues/1582> <https://github.com/espressif/esp-idf/issues/1582 <https://github.com/espressif/esp-idf/issues/1582>>
and some associated fixes by Espressif to master.
Any issues with us merging in upstream Espress ESP IDF master to our clone? See if that resolves the problem?
Regards, Mark.
On 12 Feb 2018, at 2:15 AM, Stephen Casner <casner@acm.org <mailto:casner@acm.org>> wrote:
It's been several days since I've seen any messages on this list. I suppose that Mark has been occupied by the hardware changes. Myself, I've finished the things I was working on (with the possible exception of adding an immediate-send option back into Mongoose), but I've entered a PR to get the code I added to esp-idf to support the per-task heap allocation commands accepted into the mainline and have been refining the code in response to change requests.
-- Steve _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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
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 <https://github.com/openvehicles/esp-idf.git> (fetch) origin https://github.com/openvehicles/esp-idf.git <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 <mailto: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 <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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 <mailto: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 <mailto: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 <https://github.com/openvehicles/esp-idf.git> (fetch) origin https://github.com/openvehicles/esp-idf.git <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 <mailto: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 <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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 <mailto: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 <mailto: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 <mailto: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 <https://github.com/openvehicles/esp-idf.git> (fetch) origin https://github.com/openvehicles/esp-idf.git <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 <mailto: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 <mailto:OvmsDev@lists.teslaclub.hk> > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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
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
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
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 <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
Greg, have you checked your IDF_PATH? What does "m.version" show? Regards, Michael Am 16.02.2018 um 09:27 schrieb Greg D.:
Present and accounted for. Also, when I compile code, there's no warning about cross-versions, and I have a fresh copy of esp-idf from Github. When I had the wrong branch, there was a warning about mismatched versions.
So, the git log matches, yet what I'm building doesn't; that's like, impossible, right?
Greg
Mark Webb-Johnson wrote:
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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
The string is built using git describe, which fetches the most recent tag from the current tree: balzer@leela:~/esp/esp-idf> git describe --always --tags --dirty v3.1-dev-391-g8d8d62da That's set at… balzer@leela:~/esp/esp-idf> git show v3.1-dev commit 22489d70214a5b7650ab197ffd6ab73e9c50a772 Merge: c4448714 f58c5b21 Author: Jiang Jiang Jian <jack@espressif.com> Date: Fri Dec 1 22:06:43 2017 +0800 Merge branch 'bugfix/wdt_periph_enable' into 'master' watchdogs: make sure timer group peripherals are enabled See merge request !1623 So you're missing that tag ref after doing a fresh clone… …and indeed, the tag is missing from our fork on github, it's only present in the esp origin: https://github.com/openvehicles/esp-idf/tree/v3.1-dev → 404 https://github.com/espressif/esp-idf/tree/v3.1-dev → ok So it seems we forgot to push the tags we fetched from upstream into our own fork. I did that now, so if you pull again, you should get the tag and the version string should be up to date. But that should have had no effect on your issue then, as the revision tree is consistent. Tags are just that -- tags. Another idea on your issue then: is your partition table unchanged & correct? balzer@leela:~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3> cat partitions.csv # OVMS 16MB flash ESP32 Partition Table # Name, Type, SubType, Offset, Size nvs, data, nvs, 0x9000, 0x4000 otadata, data, ota, 0xd000, 0x2000 phy_init, data, phy, 0xf000, 0x1000 factory, app, factory, 0x10000, 4M ota_0, app, ota_0, , 4M ota_1, app, ota_1, , 4M store, data, fat, , 1M Regards, Michael Am 16.02.2018 um 19:24 schrieb Greg D.:
Hi Michael,
Yes, that was one of the first things I checked. It points to /home/greg/esp/esp-idf, which is the current esp-idf directory.
m.version is this:
OVMS > metrics list m.version m.version 3.0.0/factory/main build (idf v3.0-dev-1781-g8d8d62da) Feb 15 2018 22:01:48 OVMS >
Where would I find the source of that string in the build environment?
Greg
Michael Balzer wrote:
Greg,
have you checked your IDF_PATH?
What does "m.version" show?
Regards, Michael
Am 16.02.2018 um 09:27 schrieb Greg D.:
Present and accounted for. Also, when I compile code, there's no warning about cross-versions, and I have a fresh copy of esp-idf from Github. When I had the wrong branch, there was a warning about mismatched versions.
So, the git log matches, yet what I'm building doesn't; that's like, impossible, right?
Greg
Mark Webb-Johnson wrote:
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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ 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
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Greg,
But, if I try to vfs cat the file, ovms complains that the file cannot be opened.
Just checking... Is the complaint "Error: protected path"? If so, you have to set: CONFIG_OVMS_DEV_CONFIGVFS=y in sdkconfig to allow access with the vfs commands. -- Steve
Hi Steve, No, it's just "cannot be opened:" OVMS > vfs ls /store ��������.��� ��������.��� <snip 124 lines> ��������.��� ��������.��� ovms_config OVMS > vfs cat /store/ovms_config Error: VFS file cannot be opened OVMS > vfs stat /store/ovms_config Error: VFS file cannot be opened OVMS > I just noticed that there are 128 lines of bogus files (power of 2 a coincidence?), prior to ovms_config. Greg Stephen Casner wrote:
Greg,
But, if I try to vfs cat the file, ovms complains that the file cannot be opened. Just checking... Is the complaint "Error: protected path"? If so, you have to set:
CONFIG_OVMS_DEV_CONFIGVFS=y
in sdkconfig to allow access with the vfs commands.
-- Steve _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Well, Greg, it looks like your /store is scrogged and needs to be initialized anew. No idea how that happened. If by chance you saved a copy of your files using scp then you could scp the copy back, again assuming CONFIG_OVMS_DEV_CONFIGVFS=y. -- Steve On Fri, 16 Feb 2018, Greg D. wrote:
Hi Steve,
No, it's just "cannot be opened:"
OVMS > vfs ls /store ????????????????????????.????????? ????????????????????????.????????? <snip 124 lines> ????????????????????????.????????? ????????????????????????.????????? ovms_config OVMS > vfs cat /store/ovms_config Error: VFS file cannot be opened OVMS > vfs stat /store/ovms_config Error: VFS file cannot be opened OVMS >
I just noticed that there are 128 lines of bogus files (power of 2 a coincidence?), prior to ovms_config.
Greg
Stephen Casner wrote:
Greg,
But, if I try to vfs cat the file, ovms complains that the file cannot be opened. Just checking... Is the complaint "Error: protected path"? If so, you have to set:
CONFIG_OVMS_DEV_CONFIGVFS=y
in sdkconfig to allow access with the vfs commands.
-- Steve
I have some of the files saved, but there's not a whole lot of configuring to do in any case. Not a big deal to re-initialize. Probably good to do that, just in case there's some old cruft out there that I don't remember. Unless someone has any ideas on what might have caused this, I probably should re-init Flash and move on. I've not tried to create any files or such, to not protect the guilty by destroying evidence. Last chance... ? So, if we do come to that, what is the easiest way to re-init Flash? Buttons somewhere, if I recall, but I've never done that as yet. Thanks, Greg Stephen Casner wrote:
Well, Greg, it looks like your /store is scrogged and needs to be initialized anew. No idea how that happened.
If by chance you saved a copy of your files using scp then you could scp the copy back, again assuming CONFIG_OVMS_DEV_CONFIGVFS=y.
-- Steve
On Fri, 16 Feb 2018, Greg D. wrote:
Hi Steve,
No, it's just "cannot be opened:"
OVMS > vfs ls /store ????????????????????????.????????? ????????????????????????.????????? <snip 124 lines> ????????????????????????.????????? ????????????????????????.????????? ovms_config OVMS > vfs cat /store/ovms_config Error: VFS file cannot be opened OVMS > vfs stat /store/ovms_config Error: VFS file cannot be opened OVMS >
I just noticed that there are 128 lines of bogus files (power of 2 a coincidence?), prior to ovms_config.
Greg
Stephen Casner wrote:
Greg,
But, if I try to vfs cat the file, ovms complains that the file cannot be opened. Just checking... Is the complaint "Error: protected path"? If so, you have to set:
CONFIG_OVMS_DEV_CONFIGVFS=y
in sdkconfig to allow access with the vfs commands.
-- Steve
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Ovms_config is a directory. Don’t think you can cat it. Regards, Mark
On 17 Feb 2018, at 10:32 AM, Greg D. <gregd2350@gmail.com> wrote:
Hi Steve,
No, it's just "cannot be opened:"
OVMS > vfs ls /store ��������.��� ��������.��� <snip 124 lines> ��������.��� ��������.��� ovms_config OVMS > vfs cat /store/ovms_config Error: VFS file cannot be opened OVMS > vfs stat /store/ovms_config Error: VFS file cannot be opened OVMS >
I just noticed that there are 128 lines of bogus files (power of 2 a coincidence?), prior to ovms_config.
Greg
Stephen Casner wrote:
Greg,
But, if I try to vfs cat the file, ovms complains that the file cannot be opened. Just checking... Is the complaint "Error: protected path"? If so, you have to set:
CONFIG_OVMS_DEV_CONFIGVFS=y
in sdkconfig to allow access with the vfs commands.
-- Steve _______________________________________________ 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
Ah, ok then. I did a vfs ls of it, and nothing got returned, so tried catting it. If it's a directory, what should I normally find in there? I have not tried to set any config parameters as yet. Is it worth trying to do so (writing to flash)? Greg Mark Webb-Johnson wrote:
Ovms_config is a directory. Don’t think you can cat it.
Regards, Mark
On 17 Feb 2018, at 10:32 AM, Greg D. <gregd2350@gmail.com> wrote:
Hi Steve,
No, it's just "cannot be opened:"
OVMS > vfs ls /store ��������.��� ��������.��� <snip 124 lines> ��������.��� ��������.��� ovms_config OVMS > vfs cat /store/ovms_config Error: VFS file cannot be opened OVMS > vfs stat /store/ovms_config Error: VFS file cannot be opened OVMS >
I just noticed that there are 128 lines of bogus files (power of 2 a coincidence?), prior to ovms_config.
Greg
Stephen Casner wrote:
Greg,
But, if I try to vfs cat the file, ovms complains that the file cannot be opened. Just checking... Is the complaint "Error: protected path"? If so, you have to set:
CONFIG_OVMS_DEV_CONFIGVFS=y
in sdkconfig to allow access with the vfs commands.
-- Steve _______________________________________________ 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
That would have helped. Also, shouldn't a 'stat' of it return something useful? That error about not being able to open it leaves me wondering about what is safe to do at this point. Greg Stephen Casner wrote:
On Sat, 17 Feb 2018, Mark Webb-Johnson wrote:
Ovms_config is a directory. Don't think you can cat it. Oh, right. Perhaps vfs ls should add a trailing '/'?
-- Steve _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I get the same error message if I try "vfs cat /store/scripts" (which is a directory), so I don't think that message indicates anything worse for you. If the recovery approach is to wipe flash, what harm could there be in trying to write something in the config? -- Steve On Fri, 16 Feb 2018, Greg D. wrote:
That would have helped. Also, shouldn't a 'stat' of it return something useful? That error about not being able to open it leaves me wondering about what is safe to do at this point.
Greg
Stephen Casner wrote:
On Sat, 17 Feb 2018, Mark Webb-Johnson wrote:
Ovms_config is a directory. Don't think you can cat it. Oh, right. Perhaps vfs ls should add a trailing '/'?
-- Steve
Not the recovery, the troubleshooting. Didn't want to write to it if there were any tea leaves that we needed to analyze, though come to think of it, the (empty) ovms_config directory was written there already, so... Tried creating an obd2ecu map item, and now ovms_config has a file in it, and the file contains the map. So, writing and reading work, and they survive a reboot. So, wipe it? Any last tea leaves to sift through? What is the safest way to put flash back to a good state (without having access to a programmer!)? Greg Stephen Casner wrote:
I get the same error message if I try "vfs cat /store/scripts" (which is a directory), so I don't think that message indicates anything worse for you. If the recovery approach is to wipe flash, what harm could there be in trying to write something in the config?
-- Steve
On Fri, 16 Feb 2018, Greg D. wrote:
That would have helped. Also, shouldn't a 'stat' of it return something useful? That error about not being able to open it leaves me wondering about what is safe to do at this point.
Greg
Stephen Casner wrote:
On Sat, 17 Feb 2018, Mark Webb-Johnson wrote:
Ovms_config is a directory. Don't think you can cat it. Oh, right. Perhaps vfs ls should add a trailing '/'?
-- Steve
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Since there hasn't been a huge cry for more info about my module, how does one safely (without bricking potential) re-initialize the flash? I seem to recall there was a button pressing sequence, but can't find the reference. Greg Greg D. wrote:
Not the recovery, the troubleshooting. Didn't want to write to it if there were any tea leaves that we needed to analyze, though come to think of it, the (empty) ovms_config directory was written there already, so...
Tried creating an obd2ecu map item, and now ovms_config has a file in it, and the file contains the map. So, writing and reading work, and they survive a reboot.
So, wipe it? Any last tea leaves to sift through?
What is the safest way to put flash back to a good state (without having access to a programmer!)?
Greg
Stephen Casner wrote:
I get the same error message if I try "vfs cat /store/scripts" (which is a directory), so I don't think that message indicates anything worse for you. If the recovery approach is to wipe flash, what harm could there be in trying to write something in the config?
-- Steve
On Fri, 16 Feb 2018, Greg D. wrote:
That would have helped. Also, shouldn't a 'stat' of it return something useful? That error about not being able to open it leaves me wondering about what is safe to do at this point.
Greg
Stephen Casner wrote:
On Sat, 17 Feb 2018, Mark Webb-Johnson wrote:
Ovms_config is a directory. Don't think you can cat it. Oh, right. Perhaps vfs ls should add a trailing '/'?
-- Steve
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Michael, Our own version is set in main/ovms.h as: #define OVMS_VERSION "3.0.990" That is used to generate metrics, on boot. I have just committed (and pushed) a re-work of this to do something similar to what you show here. Downside is that the main/ovms_version module has to be rebuilt each build. OVMS > metrics list m.version m.version 3.0.990-6-ga45e575/factory/main build (idf v3.1-dev-392-g3d5f7b3e) Feb 22 2018 11:16:23 Any ‘make’ gurus out there that want to improve it, please go ahead. Perhaps we can somehow depend it on the main ovms.o (so it only builds when that changes)? Regards, Mark
On 17 Feb 2018, at 7:26 AM, Michael Balzer <dexter@expeedo.de> wrote:
That's set at…
balzer@leela:~/esp/esp-idf> git show v3.1-dev commit 22489d70214a5b7650ab197ffd6ab73e9c50a772 Merge: c4448714 f58c5b21 Author: Jiang Jiang Jian <jack@espressif.com> <mailto:jack@espressif.com> Date: Fri Dec 1 22:06:43 2017 +0800
Merge branch 'bugfix/wdt_periph_enable' into 'master'
watchdogs: make sure timer group peripherals are enabled
See merge request !1623
This needs some help, but I don't qualify as a 'make' guru. Just now I pulled to get the new ovms_time and ran 'make' (within emacs, as I usually do so I can jump to the source files for errors). That compiled just the new module as expected. Then I wanted to run it, so in the shell I did "make flash monitor". That proceded to run GENCONFIG and recompile everything. While working on the updates last evening I observed that every time I did "make flash monitor" it would recompile ovms_version and link even though I had just done a 'make' beforehand. -- Steve On Thu, 22 Feb 2018, Mark Webb-Johnson wrote:
Michael,
Our own version is set in main/ovms.h as:
#define OVMS_VERSION "3.0.990"
That is used to generate metrics, on boot.
I have just committed (and pushed) a re-work of this to do something similar to what you show here. Downside is that the main/ovms_version module has to be rebuilt each build.
OVMS > metrics list m.version m.version 3.0.990-6-ga45e575/factory/main build (idf v3.1-dev-392-g3d5f7b3e) Feb 22 2018 11:16:23
Any ‘make’ gurus out there that want to improve it, please go ahead. Perhaps we can somehow depend it on the main ovms.o (so it only builds when that changes)?
Regards, Mark
On 17 Feb 2018, at 7:26 AM, Michael Balzer <dexter@expeedo.de> wrote:
That's set at…
balzer@leela:~/esp/esp-idf> git show v3.1-dev commit 22489d70214a5b7650ab197ffd6ab73e9c50a772 Merge: c4448714 f58c5b21 Author: Jiang Jiang Jian <jack@espressif.com> <mailto:jack@espressif.com> Date: Fri Dec 1 22:06:43 2017 +0800
Merge branch 'bugfix/wdt_periph_enable' into 'master'
watchdogs: make sure timer group peripherals are enabled
See merge request !1623
I just pushed a solution for this. Regards, Michael Am 24.02.2018 um 21:52 schrieb Stephen Casner:
This needs some help, but I don't qualify as a 'make' guru.
Just now I pulled to get the new ovms_time and ran 'make' (within emacs, as I usually do so I can jump to the source files for errors). That compiled just the new module as expected. Then I wanted to run it, so in the shell I did "make flash monitor". That proceded to run GENCONFIG and recompile everything.
While working on the updates last evening I observed that every time I did "make flash monitor" it would recompile ovms_version and link even though I had just done a 'make' beforehand.
-- Steve
On Thu, 22 Feb 2018, Mark Webb-Johnson wrote:
Michael,
Our own version is set in main/ovms.h as:
#define OVMS_VERSION "3.0.990"
That is used to generate metrics, on boot.
I have just committed (and pushed) a re-work of this to do something similar to what you show here. Downside is that the main/ovms_version module has to be rebuilt each build.
OVMS > metrics list m.version m.version 3.0.990-6-ga45e575/factory/main build (idf v3.1-dev-392-g3d5f7b3e) Feb 22 2018 11:16:23
Any ‘make’ gurus out there that want to improve it, please go ahead. Perhaps we can somehow depend it on the main ovms.o (so it only builds when that changes)?
Regards, Mark
On 17 Feb 2018, at 7:26 AM, Michael Balzer <dexter@expeedo.de> wrote:
That's set at…
balzer@leela:~/esp/esp-idf> git show v3.1-dev commit 22489d70214a5b7650ab197ffd6ab73e9c50a772 Merge: c4448714 f58c5b21 Author: Jiang Jiang Jian <jack@espressif.com> <mailto:jack@espressif.com> Date: Fri Dec 1 22:06:43 2017 +0800
Merge branch 'bugfix/wdt_periph_enable' into 'master'
watchdogs: make sure timer group peripherals are enabled
See merge request !1623
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
I think that makes you the ‘make guru’. Thanks, Mark.
On 25 Feb 2018, at 6:30 PM, Michael Balzer <dexter@expeedo.de> wrote:
I just pushed a solution for this.
Regards, Michael
Am 24.02.2018 um 21:52 schrieb Stephen Casner:
This needs some help, but I don't qualify as a 'make' guru.
Just now I pulled to get the new ovms_time and ran 'make' (within emacs, as I usually do so I can jump to the source files for errors). That compiled just the new module as expected. Then I wanted to run it, so in the shell I did "make flash monitor". That proceded to run GENCONFIG and recompile everything.
While working on the updates last evening I observed that every time I did "make flash monitor" it would recompile ovms_version and link even though I had just done a 'make' beforehand.
-- Steve
On Thu, 22 Feb 2018, Mark Webb-Johnson wrote:
Michael,
Our own version is set in main/ovms.h as:
#define OVMS_VERSION "3.0.990"
That is used to generate metrics, on boot.
I have just committed (and pushed) a re-work of this to do something similar to what you show here. Downside is that the main/ovms_version module has to be rebuilt each build.
OVMS > metrics list m.version m.version 3.0.990-6-ga45e575/factory/main build (idf v3.1-dev-392-g3d5f7b3e) Feb 22 2018 11:16:23
Any ‘make’ gurus out there that want to improve it, please go ahead. Perhaps we can somehow depend it on the main ovms.o (so it only builds when that changes)?
Regards, Mark
On 17 Feb 2018, at 7:26 AM, Michael Balzer <dexter@expeedo.de> <mailto:dexter@expeedo.de> wrote:
That's set at…
balzer@leela:~/esp/esp-idf> git show v3.1-dev commit 22489d70214a5b7650ab197ffd6ab73e9c50a772 Merge: c4448714 f58c5b21 Author: Jiang Jiang Jian <jack@espressif.com> <mailto:jack@espressif.com> <mailto:jack@espressif.com> <mailto:jack@espressif.com> Date: Fri Dec 1 22:06:43 2017 +0800
Merge branch 'bugfix/wdt_periph_enable' into 'master'
watchdogs: make sure timer group peripherals are enabled
See merge request !1623
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
New 3.1 hardware is looking very good. To recap: Unable to get WROOM32 modules with more than the standard 4MB flash on-board, 3.0 used an external 16MB flash chip. That worked well (in the end), but was a pain to get right. RAM was also tight, so we wanted to make sure we had room for expansion and change to a WROVER module (same as WROOM32, but with an extra 4MB flash RAM). When we tried to move the same approach to the 3.1 hardware using WROVER modules, we couldn’t get it to work. The change from 3.3v to 1.8v caused issues, but worse the Espressif IDF just didn’t support the combination of external flash and PSRAM. So, we hand-modified some WROVER modules to swap 4MB->16MB flash chip, as well as sourced a supplier of WROVER modules with 16MB flash on-board. These are now working well. I can now switch to QIO mode (which should speed things up). Previously, we had to use DIO mode (with external flash). After setting the menuconfig for that, here is what the boot loader tells us: I (30) boot: ESP-IDF v3.1-dev-391-g8d8d62da 2nd stage bootloader I (30) boot: compile time 16:24:20 I (43) boot: Enabling RNG early entropy source... I (44) qio_mode: Enabling default flash chip QIO I (44) boot: SPI Speed : 40MHz I (47) boot: SPI Mode : QIO I (51) boot: SPI Flash Size : 16MB In theory, we can go to 80MHz, but the forums have lots of comments about how tight that is on timing so we are going to stay at 40MHz. SPI RAM gets initialised just fine: I (743) spiram: SPI RAM mode: flash 40m sram 40m I (747) spiram: PSRAM initialized, cache is in low/high (2-core) mode. ... I (1656) spiram: SPI SRAM memory test OK I (1656) heap_init: Initializing. RAM available for dynamic allocation: I (1656) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM I (1663) heap_init: At 3FFBC198 len 00023E68 (143 KiB): DRAM I (1669) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM I (1675) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM I (1683) heap_init: At 40099404 len 00006BFC (26 KiB): IRAM ... I (1693) spiram: Adding pool of 4096K of external SPI memory to heap allocator OVMS > module memory Free 8-bit 119128/282436, 32-bit 424/27596, SPIRAM 4193928/4194252 --Task-- Total DRAM D/IRAM IRAM SPIRAM +/- DRAM D/IRAM IRAM SPIRAM tiT 0 0 0 128 +0 +0 +0 +128 Housekeeping 40564 5120 0 12 +40564 +5120 +0 +12 no task 5348 0 0 0 +5348 +0 +0 +0 esp_timer 52328 0 644 0 +52328 +0 +644 +0 main 16448 0 0 0 +16448 +0 +0 +0 ipc0 11096 0 0 0 +11096 +0 +0 +0 ipc1 12 0 0 0 +12 +0 +0 +0 Tmr Svc 884 6444 0 0 +884 +6444 +0 +0 AsyncConsole 108 0 26404 0 +108 +0 +26404 +0 SD CARD works well: I (1004) sdcard: SD CARD has been inserted. Auto-mounting... I (1004) gpio: GPIO[13]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 OVMS > test sdcard SD CARD test starts... SD CARD written 0/2048 SD CARD written 128/2048 SD CARD written 256/2048 SD CARD written 384/2048 SD CARD written 512/2048 SD CARD written 640/2048 SD CARD written 768/2048 SD CARD written 896/2048 SD CARD written 1024/2048 SD CARD written 1152/2048 SD CARD written 1280/2048 SD CARD written 1408/2048 SD CARD written 1536/2048 SD CARD written 1664/2048 SD CARD written 1792/2048 SD CARD written 1920/2048 Cleaning up SD CARD test completes OVMS > vfs ls /sd component.mk sd_card_example_main.c log.txt FOO.TXT stubby ovms3.done Putting an ovms3.bin into the root directory of the SD card, and rebooting, even has the desired affect of an OTA update: I (1015) sdcard: SD CARD has been inserted. Auto-mounting... I (1015) gpio: GPIO[13]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 W (1095) ota: AutoFlashSD Current running partition is: factory W (1095) ota: AutoFlashSD Target partition is: ota_0 W (1095) ota: AutoFlashSD Source image is 1582464 bytes in size W (1095) ota: AutoFlashSD Preparing flash partition... W (9315) ota: AutoFlashSD Flashing image partition... W (18275) ota: AutoFlashSD Setting boot partition... W (19215) ota: AutoFlashSD unmounting SD CARD W (19215) ota: AutoFlashSD OTA flash successful: Flashed 1582464 bytes, and booting from ‘ota_0' rst:0xc (SW_CPU_RESET),boot:0x3b (SPI_FAST_FLASH_BOOT) OVMS > ota status Firmware: 3.0.0/ota_0/main build (idf v3.1-dev-217-g5bf85d06) Jan 16 2018 08:03:11 Running partition: ota_0 Boot partition: ota_0 OVMS > metrics list m.version m.version 3.0.0/ota_0/main build (idf v3.1-dev-217-g5bf85d06) Jan 16 2018 08:03:11 CAN buses: OVMS > can can1 start active 1000000 Can bus can1 started in mode active at speed 1000000Kbps OVMS > can can2 start active 1000000 Can bus can2 started in mode active at speed 1000000Kbps OVMS > can can3 start active 1000000 Can bus can3 started in mode active at speed 1000000Kbps OVMS > can log trace CAN logging active: Type:trace; Path:''; Filter:off; Vehicle:; Note: info logging is done at log level debug, frame logging at verbose OVMS > log level verbose Logging level for * set to verbose OVMS > can can3 tx standard 100 01 02 03 04 V (1478305) canlog: TX can3 id 100 len 4: 01 02 03 04 | .... V (1478305) canlog: RX can1 id 100 len 4: 01 02 03 04 | .... V (1478305) canlog: RX can2 id 100 len 4: 01 02 03 04 | …. OVMS > can can2 tx standard 100 01 02 03 04 V (1598675) canlog: TX can2 id 100 len 4: 01 02 03 04 | .... V (1598675) canlog: RX can1 id 100 len 4: 01 02 03 04 | .... OVMS > can can1 tx standard 100 01 02 03 04 V (1688155) canlog: TX can1 id 100 len 4: 01 02 03 04 | .... V (1688155) canlog: RX can2 id 100 len 4: 01 02 03 04 | …. OVMS > can can3 tx extended 100 01 02 03 04 05 06 07 08 V (1716925) canlog: TX can3 id 00000100 len 8: 01 02 03 04 05 06 07 08 | ........ V (1716925) canlog: RX can1 id 00000100 len 8: 01 02 03 04 05 06 07 08 | ........ V (1716925) canlog: RX can2 id 00000100 len 8: 01 02 03 04 05 06 07 08 | ........ Seems to be a problem with receiving on CAN3. Doesn’t really make sense, as it can transmit. I’ll look into this. Still a few things to check, but it seems we are ok for 3.1 production. Now on to the SPI RAM support. Planning a base class that can be derived from. Objects there will be allocated from SPI RAM as highest priority (but normal RAM for 3.0 hardware without SPI RAM). Regards, Mark.
That looks very promising now, thanks for the update! Regards, Michael Am 16.02.2018 um 10:33 schrieb Mark Webb-Johnson:
New 3.1 hardware is looking very good.
To recap: Unable to get WROOM32 modules with more than the standard 4MB flash on-board, 3.0 used an external 16MB flash chip. That worked well (in the end), but was a pain to get right. RAM was also tight, so we wanted to make sure we had room for expansion and change to a WROVER module (same as WROOM32, but with an extra 4MB flash RAM). When we tried to move the same approach to the 3.1 hardware using WROVER modules, we couldn’t get it to work. The change from 3.3v to 1.8v caused issues, but worse the Espressif IDF just didn’t support the combination of external flash and PSRAM. So, we hand-modified some WROVER modules to swap 4MB->16MB flash chip, as well as sourced a supplier of WROVER modules with 16MB flash on-board. These are now working well.
I can now switch to QIO mode (which should speed things up). Previously, we had to use DIO mode (with external flash). After setting the menuconfig for that, here is what the boot loader tells us:
I (30) boot: ESP-IDF v3.1-dev-391-g8d8d62da 2nd stage bootloader I (30) boot: compile time 16:24:20 I (43) boot: Enabling RNG early entropy source... I (44) qio_mode: Enabling default flash chip QIO I (44) boot: SPI Speed : 40MHz I (47) boot: SPI Mode : QIO I (51) boot: SPI Flash Size : 16MB
In theory, we can go to 80MHz, but the forums have lots of comments about how tight that is on timing so we are going to stay at 40MHz.
SPI RAM gets initialised just fine:
I (743) spiram: SPI RAM mode: flash 40m sram 40m I (747) spiram: PSRAM initialized, cache is in low/high (2-core) mode. ... I (1656) spiram: SPI SRAM memory test OK I (1656) heap_init: Initializing. RAM available for dynamic allocation: I (1656) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM I (1663) heap_init: At 3FFBC198 len 00023E68 (143 KiB): DRAM I (1669) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM I (1675) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM I (1683) heap_init: At 40099404 len 00006BFC (26 KiB): IRAM ... I (1693) spiram: Adding pool of 4096K of external SPI memory to heap allocator
OVMS > module memory Free 8-bit 119128/282436, 32-bit 424/27596, SPIRAM 4193928/4194252 --Task-- Total DRAM D/IRAM IRAM SPIRAM +/- DRAM D/IRAM IRAM SPIRAM tiT 0 0 0 128 +0 +0 +0 +128 Housekeeping 40564 5120 0 12 +40564 +5120 +0 +12 no task 5348 0 0 0 +5348 +0 +0 +0 esp_timer 52328 0 644 0 +52328 +0 +644 +0 main 16448 0 0 0 +16448 +0 +0 +0 ipc0 11096 0 0 0 +11096 +0 +0 +0 ipc1 12 0 0 0 +12 +0 +0 +0 Tmr Svc 884 6444 0 0 +884 +6444 +0 +0 AsyncConsole 108 0 26404 0 +108 +0 +26404 +0
SD CARD works well:
I (1004) sdcard: SD CARD has been inserted. Auto-mounting... I (1004) gpio: GPIO[13]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 OVMS > test sdcard SD CARD test starts... SD CARD written 0/2048 SD CARD written 128/2048 SD CARD written 256/2048 SD CARD written 384/2048 SD CARD written 512/2048 SD CARD written 640/2048 SD CARD written 768/2048 SD CARD written 896/2048 SD CARD written 1024/2048 SD CARD written 1152/2048 SD CARD written 1280/2048 SD CARD written 1408/2048 SD CARD written 1536/2048 SD CARD written 1664/2048 SD CARD written 1792/2048 SD CARD written 1920/2048 Cleaning up SD CARD test completes
OVMS > vfs ls /sd component.mk sd_card_example_main.c log.txt FOO.TXT stubby ovms3.done
Putting an ovms3.bin into the root directory of the SD card, and rebooting, even has the desired affect of an OTA update:
I (1015) sdcard: SD CARD has been inserted. Auto-mounting... I (1015) gpio: GPIO[13]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 W (1095) ota: AutoFlashSD Current running partition is: factory W (1095) ota: AutoFlashSD Target partition is: ota_0 W (1095) ota: AutoFlashSD Source image is 1582464 bytes in size W (1095) ota: AutoFlashSD Preparing flash partition... W (9315) ota: AutoFlashSD Flashing image partition... W (18275) ota: AutoFlashSD Setting boot partition... W (19215) ota: AutoFlashSD unmounting SD CARD W (19215) ota: AutoFlashSD OTA flash successful: Flashed 1582464 bytes, and booting from ‘ota_0'
rst:0xc (SW_CPU_RESET),boot:0x3b (SPI_FAST_FLASH_BOOT)
OVMS > ota status Firmware: 3.0.0/ota_0/main build (idf v3.1-dev-217-g5bf85d06) Jan 16 2018 08:03:11 Running partition: ota_0 Boot partition: ota_0
OVMS > metrics list m.version m.version 3.0.0/ota_0/main build (idf v3.1-dev-217-g5bf85d06) Jan 16 2018 08:03:11
CAN buses:
OVMS > can can1 start active 1000000 Can bus can1 started in mode active at speed 1000000Kbps
OVMS > can can2 start active 1000000 Can bus can2 started in mode active at speed 1000000Kbps
OVMS > can can3 start active 1000000 Can bus can3 started in mode active at speed 1000000Kbps
OVMS > can log trace CAN logging active: Type:trace; Path:''; Filter:off; Vehicle:; Note: info logging is done at log level debug, frame logging at verbose
OVMS > log level verbose Logging level for * set to verbose
OVMS > can can3 tx standard 100 01 02 03 04 V (1478305) canlog: TX can3 id 100 len 4: 01 02 03 04 | .... V (1478305) canlog: RX can1 id 100 len 4: 01 02 03 04 | .... V (1478305) canlog: RX can2 id 100 len 4: 01 02 03 04 | ….
OVMS > can can2 tx standard 100 01 02 03 04 V (1598675) canlog: TX can2 id 100 len 4: 01 02 03 04 | .... V (1598675) canlog: RX can1 id 100 len 4: 01 02 03 04 | ....
OVMS > can can1 tx standard 100 01 02 03 04 V (1688155) canlog: TX can1 id 100 len 4: 01 02 03 04 | .... V (1688155) canlog: RX can2 id 100 len 4: 01 02 03 04 | ….
OVMS > can can3 tx extended 100 01 02 03 04 05 06 07 08 V (1716925) canlog: TX can3 id 00000100 len 8: 01 02 03 04 05 06 07 08 | ........ V (1716925) canlog: RX can1 id 00000100 len 8: 01 02 03 04 05 06 07 08 | ........ V (1716925) canlog: RX can2 id 00000100 len 8: 01 02 03 04 05 06 07 08 | ........
Seems to be a problem with receiving on CAN3. Doesn’t really make sense, as it can transmit. I’ll look into this.
Still a few things to check, but it seems we are ok for 3.1 production.
Now on to the SPI RAM support. Planning a base class that can be derived from. Objects there will be allocated from SPI RAM as highest priority (but normal RAM for 3.0 hardware without SPI RAM).
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Mark, I went back and reread all your messages about WROOM32 and WROVER and AnalogLamb because I had not internalized all the tradeoffs. I guess the development that allowed reaching a successful v3.1 design was finding an acceptable source for WROVER modules with 16MB flash inside. Are these espressif WROVER modules that are modified by a third party, or is that third party building up their own from the open-source design? (You said nobody is making these as standard products.) And if the latter, are you considering building your own because you could lower the cost? To me, it seems silly that espressif did not just put the 16MB flash in the WROVER to start with unless there is a significant difference in the price of 4MB and 16MB chips. A few days ago you were waiting for samples of the 16MB WROVER modules because your attempts to update existing modules were "hit-and-miss". I guess the 16MB modules must not have arrived yet since you resorted to hand-soldering your own. Congratulations on finally achieving a good result! You said these 16MB WROVER modules are significantly more expensive, but I don't know how to quantify that. If it is $10 or less and so long at the lead time is not "who knows when", I would have given in a long time ago considering all the grief you and the China team have gone through. Clearly having both flash and RAM inside the module is the best solution.
Thanks Steve, for all that 'module memory' work - I hope Espressif accept it upstream because it is incredibly useful.
Indeed, just last evening @projectgus gave me a "LGTM" for my changes after I had addressed his requests in response to the initial PR. I think that means my changes go into the "review and merge queue" but I don't know how long until that merge happens. This latest version does require an API change which means another flag day for our code. The change is to put all the parameters into a struct rather than having a too-long list of function parameters. I have that in a local branch of ovms at the moment. -- Steve
Things available: * Espressif WROOM32. 4MB flash. * Espressif WROVER. 4MB flash + 4MB SPIRAM. * Clones for both the above (based on open source designs). * Analog Lamb ALB32-WROVER. WROOM32 format module with 4MB flash + 4MB SPIRAM. 8MB flash version available. 16MB flash version also supposedly available, but always on back order. * Analog Lamb WROVER. WROVER format module with 4MB/8MB/16MB flash + 4MB SPIRAM. 8MB and 16MB versions are custom order. * Custom hacked WROVER modules. Shield removed, then 4MB->16MB flash upgrade performed. Early attempts at hacking failed. Probably baked the chips trying to get the shield off. It is a big hunk of metal. We seem to have improved, and have had more success. However, I wouldn’t want to make 100 that way. We are going to use Analog Lamb WROVER with 16MB flash + 4MB SPIRAM for the first production run. We have a couple of samples of these, and they work well. Exactly the same as the custom hacked ones we made ourselves. They build these themselves and will simply replace 4MB flash chip with 16MB chip during production, then put the shield on. A 4MB WROVER module is about us$4. A 16MB WROVER from AnalogLamb is close to us$10. BOM cost difference is <us$1. So, yes we are looking into making our own because of cost. Regards, Mark
On 17 Feb 2018, at 8:02 AM, Stephen Casner <casner@acm.org> wrote:
Mark,
I went back and reread all your messages about WROOM32 and WROVER and AnalogLamb because I had not internalized all the tradeoffs. I guess the development that allowed reaching a successful v3.1 design was finding an acceptable source for WROVER modules with 16MB flash inside. Are these espressif WROVER modules that are modified by a third party, or is that third party building up their own from the open-source design? (You said nobody is making these as standard products.) And if the latter, are you considering building your own because you could lower the cost?
To me, it seems silly that espressif did not just put the 16MB flash in the WROVER to start with unless there is a significant difference in the price of 4MB and 16MB chips.
A few days ago you were waiting for samples of the 16MB WROVER modules because your attempts to update existing modules were "hit-and-miss". I guess the 16MB modules must not have arrived yet since you resorted to hand-soldering your own. Congratulations on finally achieving a good result! You said these 16MB WROVER modules are significantly more expensive, but I don't know how to quantify that. If it is $10 or less and so long at the lead time is not "who knows when", I would have given in a long time ago considering all the grief you and the China team have gone through. Clearly having both flash and RAM inside the module is the best solution.
Thanks Steve, for all that 'module memory' work - I hope Espressif accept it upstream because it is incredibly useful.
Indeed, just last evening @projectgus gave me a "LGTM" for my changes after I had addressed his requests in response to the initial PR. I think that means my changes go into the "review and merge queue" but I don't know how long until that merge happens. This latest version does require an API change which means another flag day for our code. The change is to put all the parameters into a struct rather than having a too-long list of function parameters. I have that in a local branch of ovms at the moment.
-- Steve _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Mark Thanks for the details of the module supply options. As I said, from my perspective the cost difference for the AnalogLamb device should be easily supported by the intended market and not worth all the grief you and China team have gone through. No matter, it's great that we now have a solution that gets us where we want to be so production can start. -- Steve On Sat, 17 Feb 2018, Mark Webb-Johnson wrote:
Things available:
* Espressif WROOM32. 4MB flash. * Espressif WROVER. 4MB flash + 4MB SPIRAM. * Clones for both the above (based on open source designs). * Analog Lamb ALB32-WROVER. WROOM32 format module with 4MB flash + 4MB SPIRAM. 8MB flash version available. 16MB flash version also supposedly available, but always on back order. * Analog Lamb WROVER. WROVER format module with 4MB/8MB/16MB flash + 4MB SPIRAM. 8MB and 16MB versions are custom order. * Custom hacked WROVER modules. Shield removed, then 4MB->16MB flash upgrade performed.
Early attempts at hacking failed. Probably baked the chips trying to get the shield off. It is a big hunk of metal. We seem to have improved, and have had more success. However, I wouldn't want to make 100 that way.
We are going to use Analog Lamb WROVER with 16MB flash + 4MB SPIRAM for the first production run. We have a couple of samples of these, and they work well. Exactly the same as the custom hacked ones we made ourselves. They build these themselves and will simply replace 4MB flash chip with 16MB chip during production, then put the shield on.
A 4MB WROVER module is about us$4. A 16MB WROVER from AnalogLamb is close to us$10. BOM cost difference is <us$1. So, yes we are looking into making our own because of cost.
Regards, Mark
On 17 Feb 2018, at 8:02 AM, Stephen Casner <casner@acm.org> wrote:
Mark,
I went back and reread all your messages about WROOM32 and WROVER and AnalogLamb because I had not internalized all the tradeoffs. I guess the development that allowed reaching a successful v3.1 design was finding an acceptable source for WROVER modules with 16MB flash inside. Are these espressif WROVER modules that are modified by a third party, or is that third party building up their own from the open-source design? (You said nobody is making these as standard products.) And if the latter, are you considering building your own because you could lower the cost?
To me, it seems silly that espressif did not just put the 16MB flash in the WROVER to start with unless there is a significant difference in the price of 4MB and 16MB chips.
A few days ago you were waiting for samples of the 16MB WROVER modules because your attempts to update existing modules were "hit-and-miss". I guess the 16MB modules must not have arrived yet since you resorted to hand-soldering your own. Congratulations on finally achieving a good result! You said these 16MB WROVER modules are significantly more expensive, but I don't know how to quantify that. If it is $10 or less and so long at the lead time is not "who knows when", I would have given in a long time ago considering all the grief you and the China team have gone through. Clearly having both flash and RAM inside the module is the best solution.
Thanks Steve, for all that 'module memory' work - I hope Espressif accept it upstream because it is incredibly useful.
Indeed, just last evening @projectgus gave me a "LGTM" for my changes after I had addressed his requests in response to the initial PR. I think that means my changes go into the "review and merge queue" but I don't know how long until that merge happens. This latest version does require an API change which means another flag day for our code. The change is to put all the parameters into a struct rather than having a too-long list of function parameters. I have that in a local branch of ovms at the moment.
-- Steve
participants (5)
-
Greg D -
Greg D.
-
Mark Webb-Johnson -
Michael Balzer -
Stephen Casner