I’ll start with my priority question, then summarize a few things I’ve learned that might be of interest. Q: How do I convince git to update the esp-idf branch? I grabbed the v2.1 release branch and built it without any obvious errors, but I don’t know how to pull or otherwise check that I have the latest. Here’s a snapshot of my current state: $ git status HEAD detached at origin/release/v2.1 nothing to commit, working directory clean $ git branch * (detached from origin/release/v2.1) master $ git pull remote: Counting objects: 189, done. remote: Compressing objects: 100% (50/50), done. remote: Total 189 (delta 141), reused 185 (delta 137), pack-reused 0 Receiving objects: 100% (189/189), 27.68 KiB | 0 bytes/s, done. Resolving deltas: 100% (141/141), completed with 55 local objects. From https://github.com/espressif/esp-idf e6afe28..de750e9 master -> origin/master You are not currently on a branch. Please specify which branch you want to merge with. See git-pull(1) for details. git pull <remote> <branch> $ git pull You are not currently on a branch. Please specify which branch you want to merge with. See git-pull(1) for details. git pull <remote> <branch> $ A: After reading the warnings about the Silicon Labs driver crashes, I decided to host my efforts on OS X Yosemite, 10.10.5, instead of any newer macOS. Therefore, I installed the legacy driver. So far, I’ve not had any problems. I’m able to connect to the OVMS v3 and communicate. I am using a cheap, $4.99 Full Speed USB hub (unpowered, because I’m too lazy to hunt for the wall wart adaptor). I realize that a powered hub is recommended, but I’ve not had any issues yet. B: Those of you who may not be familiar with the ‘screen’ application might be interested to read that I am able to connect to the USB serial converter using that program without running ‘make monitor’ - the only drawback is that I have to type Control-j instead of return/enter (but that might be resolved by another command line option that I’m not familiar with yet). The command is ‘screen /dev/tty.SLAB_USBtoUART 115200’ I’m avoiding /dev/cu.SLAB_USBtoUART because I assume it might activate the RTS / DTR / etc lines and cause unexpected results. C: I’m often quite paranoid about checking that new hardware is functional before I try building my own firmware, erasing any existing firmware, and therefore basically avoid trying too many steps in the first volley. Although I’ve build the esp-idf environment, I haven’t run ‘make monitor’ yet, so I was happy to see that the OVMS v3 shipped with a working firmware already installed (*). Using the ‘screen’ command detailed above, I am able to connect to the device, turn on the wifi, and execute commands. OVMS > ota status Firmware: 3.0.0/factory/main build (idf v2.1-2-g7138fb02) Sep 21 2017 20:33:27 Running partition: factory Boot partition: factory OVMS > wifi mode ap TR25 Starting WIFI as access point... I (575846) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE I (575846) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE W (576526) phy_init: failed to load RF calibration data (0x1102), falling back to full calibration I (576706) phy: phy_version: 355.1, 59464c5, Jun 14 2017, 20:25:06, 0, 2 I (575846) wifi: wifi firmware version: 407bb27 I (575846) wifi: config NVS flash: enabled I (575846) wifi: config nano formating: disabled I (575866) wifi: Init dynamic tx buffer num: 32 I (575866) wifi: Init dynamic rx buffer num: 32 I (575866) wifi: wifi driver task: 3ffe9ad8, prio:23, stack:4096 I (575866) wifi: Init static rx buffer num: 10 I (575866) wifi: Init dynamic rx buffer num: 32 I (575866) wifi: Init rx ampdu len mblock:7 I (575866) wifi: Init lldesc rx ampdu entry mblock:4 I (575866) wifi: wifi power manager task: 0x3ffef880 prio: 21 stack: 2560 I (576526) wifi: wifi timer task: 3fff0af0, prio:22, stack:3584 I (576706) wifi: mode : softAP (30:ae:a4:37:25:85) I (576716) ovms-mdns: Launching MDNS service [Join...] I (643136) wifi: n:1 0, o:1 0, ap:1 1, sta:255 255, prof:1 I (643146) wifi: station: f4:5c:89:a3:64:cd join, AID=1, g, 20 [Leave...] I (789976) wifi: station: f4:5c:89:a3:64:cd leave, AID = 1 I (789976) wifi: n:1 0, o:1 0, ap:1 1, sta:255 255, prof:1 D: My next step is obviously to build the latest OVMS v3 firmware from git. I’m not having any trouble pulling the latest source updates because we’re not working on a branch, and it’s much easier to use git commands when working from the head / master (at least for me - I’m way more familiar with Subversion). Brian Willoughby * I don’t know whether Mark had to manually install the OVMS v3 firmware on each of these preliminary units, or if the assembly / manufacturing process is already set up to install an initial firmware on new boards. Either way, it’s nice that it didn’t arrive with a blank Flash!
Q: How do I convince git to update the esp-idf branch?
I tried the following (from developer’s guide): $ git clone https://github.com/espressif/esp-idf.git <https://github.com/espressif/esp-idf.git> $ cd 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 $ git checkout remotes/origin/release/v2.1 $ git branch * (HEAD detached at origin/release/v2.1) master $ git submodule update --init That seemed ok, and a straight git pull on that origin seems to work: $ git pull origin release/v2.1 From https://github.com/openvehicles/esp-idf <https://github.com/openvehicles/esp-idf> * branch release/v2.1 -> FETCH_HEAD Already up-to-date. (Note, I’m using the openvehicles fork, but it should be the same) Or, a ‘git fetch’ may be simpler: $ git fetch -v From https://github.com/openvehicles/esp-idf <https://github.com/openvehicles/esp-idf> = [up to date] feature/psram_malloc -> origin/feature/psram_malloc = [up to date] master -> origin/master = [up to date] release/v2.0 -> origin/release/v2.0 = [up to date] release/v2.1 -> origin/release/v2.1 There may be a better way (I’m far from a git expert), but that is how I do it.
* I don’t know whether Mark had to manually install the OVMS v3 firmware on each of these preliminary units, or if the assembly / manufacturing process is already set up to install an initial firmware on new boards. Either way, it’s nice that it didn’t arrive with a blank Flash!
The manufacturer is setup and used these 10 as a trial run to do the eFuse burning, and factory firmware burning. I also did it, with latest, to be 100% certain the 10 were ok before sending out. This is why I’ve been scrambling to get OTA working. If we can get that done, then it becomes a simple ‘ota flash http’ command to do an over-the-air update. Desperately trying to get a workable first firmware together, as feature rich as possible, to serve as factory firmware - the updates can come over the air, so long as the basic factory firmware supports it. On that topic, I’d appreciate it if those of you with the latest firmware (today’s) can try a ‘ota flash http’ and see if it works for you. You’ll need to do a ‘ota boot factory’ afterwards, to make sure it boots from factory partition, afterwards (as normally ‘ota flash http’ will switch to ota partition after a successful flash). Regards, Mark
On 6 Oct 2017, at 5:02 PM, HONDA S-2000 <s2000@audiobanshee.com> wrote:
I’ll start with my priority question, then summarize a few things I’ve learned that might be of interest.
Q: How do I convince git to update the esp-idf branch?
I grabbed the v2.1 release branch and built it without any obvious errors, but I don’t know how to pull or otherwise check that I have the latest. Here’s a snapshot of my current state:
$ git status HEAD detached at origin/release/v2.1 nothing to commit, working directory clean $ git branch * (detached from origin/release/v2.1) master $ git pull remote: Counting objects: 189, done. remote: Compressing objects: 100% (50/50), done. remote: Total 189 (delta 141), reused 185 (delta 137), pack-reused 0 Receiving objects: 100% (189/189), 27.68 KiB | 0 bytes/s, done. Resolving deltas: 100% (141/141), completed with 55 local objects. From https://github.com/espressif/esp-idf <https://github.com/espressif/esp-idf> e6afe28..de750e9 master -> origin/master You are not currently on a branch. Please specify which branch you want to merge with. See git-pull(1) for details.
git pull <remote> <branch>
$ git pull You are not currently on a branch. Please specify which branch you want to merge with. See git-pull(1) for details.
git pull <remote> <branch>
$
A: After reading the warnings about the Silicon Labs driver crashes, I decided to host my efforts on OS X Yosemite, 10.10.5, instead of any newer macOS. Therefore, I installed the legacy driver. So far, I’ve not had any problems. I’m able to connect to the OVMS v3 and communicate. I am using a cheap, $4.99 Full Speed USB hub (unpowered, because I’m too lazy to hunt for the wall wart adaptor). I realize that a powered hub is recommended, but I’ve not had any issues yet.
B: Those of you who may not be familiar with the ‘screen’ application might be interested to read that I am able to connect to the USB serial converter using that program without running ‘make monitor’ - the only drawback is that I have to type Control-j instead of return/enter (but that might be resolved by another command line option that I’m not familiar with yet).
The command is ‘screen /dev/tty.SLAB_USBtoUART 115200’ I’m avoiding /dev/cu.SLAB_USBtoUART because I assume it might activate the RTS / DTR / etc lines and cause unexpected results.
C: I’m often quite paranoid about checking that new hardware is functional before I try building my own firmware, erasing any existing firmware, and therefore basically avoid trying too many steps in the first volley. Although I’ve build the esp-idf environment, I haven’t run ‘make monitor’ yet, so I was happy to see that the OVMS v3 shipped with a working firmware already installed (*). Using the ‘screen’ command detailed above, I am able to connect to the device, turn on the wifi, and execute commands.
OVMS > ota status Firmware: 3.0.0/factory/main build (idf v2.1-2-g7138fb02) Sep 21 2017 20:33:27 Running partition: factory Boot partition: factory
OVMS > wifi mode ap TR25 Starting WIFI as access point... I (575846) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE I (575846) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE W (576526) phy_init: failed to load RF calibration data (0x1102), falling back to full calibration I (576706) phy: phy_version: 355.1, 59464c5, Jun 14 2017, 20:25:06, 0, 2 I (575846) wifi: wifi firmware version: 407bb27 I (575846) wifi: config NVS flash: enabled I (575846) wifi: config nano formating: disabled I (575866) wifi: Init dynamic tx buffer num: 32 I (575866) wifi: Init dynamic rx buffer num: 32 I (575866) wifi: wifi driver task: 3ffe9ad8, prio:23, stack:4096 I (575866) wifi: Init static rx buffer num: 10 I (575866) wifi: Init dynamic rx buffer num: 32 I (575866) wifi: Init rx ampdu len mblock:7 I (575866) wifi: Init lldesc rx ampdu entry mblock:4 I (575866) wifi: wifi power manager task: 0x3ffef880 prio: 21 stack: 2560 I (576526) wifi: wifi timer task: 3fff0af0, prio:22, stack:3584 I (576706) wifi: mode : softAP (30:ae:a4:37:25:85) I (576716) ovms-mdns: Launching MDNS service [Join...] I (643136) wifi: n:1 0, o:1 0, ap:1 1, sta:255 255, prof:1 I (643146) wifi: station: f4:5c:89:a3:64:cd join, AID=1, g, 20 [Leave...] I (789976) wifi: station: f4:5c:89:a3:64:cd leave, AID = 1 I (789976) wifi: n:1 0, o:1 0, ap:1 1, sta:255 255, prof:1
D: My next step is obviously to build the latest OVMS v3 firmware from git. I’m not having any trouble pulling the latest source updates because we’re not working on a branch, and it’s much easier to use git commands when working from the head / master (at least for me - I’m way more familiar with Subversion).
Brian Willoughby
* I don’t know whether Mark had to manually install the OVMS v3 firmware on each of these preliminary units, or if the assembly / manufacturing process is already set up to install an initial firmware on new boards. Either way, it’s nice that it didn’t arrive with a blank Flash!
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On Fri, 6 Oct 2017, Mark Webb-Johnson wrote:
On that topic, I’d appreciate it if those of you with the latest firmware (today’s) can try a ‘ota flash http’ and see if it works for you.
Crashed: OVMS > ota flash http Current running partition is: factory Target partition is: ota_0 Download firmware from api.openvehicles.com/firmware/ota/v3/main/ovms3.bin to ota_0 Error: Request failed Guru Meditation Error of type LoadProhibited occurred on core 1. Exception was unhandled. -- Steve
I think that is because no network connection available (wifi). Can you try with wifi up, running, and an IP address assigned? Seems stack gets messed up in that case. I’ll try to find out why, but the backtrace isn’t helping much. Regards, mark.
On 7 Oct 2017, at 2:53 PM, Stephen Casner <casner@acm.org> wrote:
On Fri, 6 Oct 2017, Mark Webb-Johnson wrote:
On that topic, I’d appreciate it if those of you with the latest firmware (today’s) can try a ‘ota flash http’ and see if it works for you.
Crashed:
OVMS > ota flash http Current running partition is: factory Target partition is: ota_0 Download firmware from api.openvehicles.com/firmware/ota/v3/main/ovms3.bin to ota_0 Error: Request failed Guru Meditation Error of type LoadProhibited occurred on core 1. Exception was unhandled.
-- Steve_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On Sun, 8 Oct 2017, Mark Webb-Johnson wrote:
I think that is because no network connection available (wifi). Can you try with wifi up, running, and an IP address assigned?
OVMS > ota flash http Current running partition is: factory Target partition is: ota_0 Download firmware from api.openvehicles.com/firmware/ota/v3/main/ovms3.bin to ota_0 Checksum is ae7b3ab032f6a5be7a8789650c76ea52 and expected file size is 927777 Preparing flash partition... Downloading... (100943 bytes so far) Downloading... (201095 bytes so far) Downloading... (301399 bytes so far) Downloading... (402139 bytes so far) Downloading... (502879 bytes so far) Downloading... (603771 bytes so far) Downloading... (704359 bytes so far) Downloading... (805099 bytes so far) Downloading... (905839 bytes so far) Download file length is 927744 and digest ae7b3ab032f6a5be7a8789650c76ea52 Setting boot partition... OTA flash was successfull Flashed 927744 bytes from api.openvehicles.com/firmware/ota/v3/main/ovms3.bin Next boot will be from 'ota_0'
Seems stack gets messed up in that case. I'll try to find out why, but the backtrace isn't helping much.
You may have noticed that in 57aab41 I fixed the bug that caused the crash. The OvmsHttpClient::m_buf variable was not initialized. Now without the wifi connection I get: OVMS > ota flash http Current running partition is: factory Target partition is: ota_0 Download firmware from api.openvehicles.com/firmware/ota/v3/main/ovms3.bin to ota_0 Error: Request failed W (8297) net: DNS lookup on api.openvehicles.com failed err=202 -- Steve
Steve,
You may have noticed that in 57aab41 I fixed the bug that caused the crash. The OvmsHttpClient::m_buf variable was not initialized.
Thanks for that. Nice find. Works for me: Welcome to the Open Vehicle Monitoring System (OVMS) - Async Console OVMS > ota flash http Current running partition is: factory Target partition is: ota_0 Download firmware from api.openvehicles.com/firmware/ota/v3/main/ovms3.bin to ota_0 Error: Request failed W (7274) net: DNS lookup on api.openvehicles.com failed err=202 Feel bad about that one. I (almost) never do that (I push myself into the habit of adding initialisers and destructors when I create the member variable). Not sure how that slipped through, but it explains the weird stack mess.
OVMS > ota flash http OTA flash was successfull Flashed 927744 bytes from api.openvehicles.com/firmware/ota/v3/main/ovms3.bin Next boot will be from ‘ota_0'
Looks good! (apart from the spelling error, now fixed) Regards, Mark.
On 9 Oct 2017, at 2:16 PM, Stephen Casner <casner@acm.org> wrote:
On Sun, 8 Oct 2017, Mark Webb-Johnson wrote:
I think that is because no network connection available (wifi). Can you try with wifi up, running, and an IP address assigned?
OVMS > ota flash http Current running partition is: factory Target partition is: ota_0 Download firmware from api.openvehicles.com/firmware/ota/v3/main/ovms3.bin to ota_0 Checksum is ae7b3ab032f6a5be7a8789650c76ea52 and expected file size is 927777 Preparing flash partition... Downloading... (100943 bytes so far) Downloading... (201095 bytes so far) Downloading... (301399 bytes so far) Downloading... (402139 bytes so far) Downloading... (502879 bytes so far) Downloading... (603771 bytes so far) Downloading... (704359 bytes so far) Downloading... (805099 bytes so far) Downloading... (905839 bytes so far) Download file length is 927744 and digest ae7b3ab032f6a5be7a8789650c76ea52 Setting boot partition... OTA flash was successfull Flashed 927744 bytes from api.openvehicles.com/firmware/ota/v3/main/ovms3.bin Next boot will be from 'ota_0'
Seems stack gets messed up in that case. I'll try to find out why, but the backtrace isn't helping much.
You may have noticed that in 57aab41 I fixed the bug that caused the crash. The OvmsHttpClient::m_buf variable was not initialized. Now without the wifi connection I get:
OVMS > ota flash http Current running partition is: factory Target partition is: ota_0 Download firmware from api.openvehicles.com/firmware/ota/v3/main/ovms3.bin to ota_0 Error: Request failed W (8297) net: DNS lookup on api.openvehicles.com failed err=202
-- Steve _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Debugging this was simple. In gdb's stack trace, frame 0 pointed to the 'delete' in the destructor that referenced the invalid address due to the uninitialized value. -- Steve
On Oct 8, 2017, at 11:31 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Steve,
You may have noticed that in 57aab41 I fixed the bug that caused the crash. The OvmsHttpClient::m_buf variable was not initialized.
Thanks for that. Nice find. Works for me:
Welcome to the Open Vehicle Monitoring System (OVMS) - Async Console OVMS > ota flash http Current running partition is: factory Target partition is: ota_0 Download firmware from api.openvehicles.com/firmware/ota/v3/main/ovms3.bin to ota_0 Error: Request failed W (7274) net: DNS lookup on api.openvehicles.com failed err=202
Feel bad about that one. I (almost) never do that (I push myself into the habit of adding initialisers and destructors when I create the member variable). Not sure how that slipped through, but it explains the weird stack mess.
OVMS > ota flash http OTA flash was successfull Flashed 927744 bytes from api.openvehicles.com/firmware/ota/v3/main/ovms3.bin Next boot will be from ‘ota_0'
Looks good! (apart from the spelling error, now fixed)
Regards, Mark.
On 9 Oct 2017, at 2:16 PM, Stephen Casner <casner@acm.org> wrote:
On Sun, 8 Oct 2017, Mark Webb-Johnson wrote:
I think that is because no network connection available (wifi). Can you try with wifi up, running, and an IP address assigned?
OVMS > ota flash http Current running partition is: factory Target partition is: ota_0 Download firmware from api.openvehicles.com/firmware/ota/v3/main/ovms3.bin to ota_0 Checksum is ae7b3ab032f6a5be7a8789650c76ea52 and expected file size is 927777 Preparing flash partition... Downloading... (100943 bytes so far) Downloading... (201095 bytes so far) Downloading... (301399 bytes so far) Downloading... (402139 bytes so far) Downloading... (502879 bytes so far) Downloading... (603771 bytes so far) Downloading... (704359 bytes so far) Downloading... (805099 bytes so far) Downloading... (905839 bytes so far) Download file length is 927744 and digest ae7b3ab032f6a5be7a8789650c76ea52 Setting boot partition... OTA flash was successfull Flashed 927744 bytes from api.openvehicles.com/firmware/ota/v3/main/ovms3.bin Next boot will be from 'ota_0'
Seems stack gets messed up in that case. I'll try to find out why, but the backtrace isn't helping much.
You may have noticed that in 57aab41 I fixed the bug that caused the crash. The OvmsHttpClient::m_buf variable was not initialized. Now without the wifi connection I get:
OVMS > ota flash http Current running partition is: factory Target partition is: ota_0 Download firmware from api.openvehicles.com/firmware/ota/v3/main/ovms3.bin to ota_0 Error: Request failed W (8297) net: DNS lookup on api.openvehicles.com failed err=202
-- 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
participants (5)
-
HONDA S-2000 -
Julien “JaXX” Banchet -
Mark Webb-Johnson -
Michael Balzer -
Stephen Casner