My v3.1 test board seems stable, and we are ready for hardware production. I’m ordering the components with relatively long lead times (weeks) now, and the production order will go in as soon as China comes back from holiday (next week). First hardware batch will be available during March. I know lots of people are waiting for this, but I have to balance that against risk (should some hardware issue be found during wider real-world testing). I currently plan to order 120 modules (including 60 USA 3G modems, and 60 EU 3G modems) for the first batch. 100 will go to FastTech (for general ordering), and 20 to me (for special cases). As with OVMS v1, we’ll clearly say these are early units for ‘technically capable’ people, and the firmware still has a way to go. On the firmware side, we need to move to a production style release cycle, and I will need to provide the first ‘factory’ firmware around the second week of March. Accordingly, I’m setting up some clean build environments and OTA release repositories (so I can cleanly build v3.0 and v3.1 firmware and have it available for OTA download). I have created a changes.txt log file in the root of the project. I would appreciate it if those with commit access to master could update that file when they merge/commit changes to the project. The top of the file will contain an entry for the ‘next’ version, so the change text just needs to be added below that. When the version is ready to go, I will update changes.txt with the date and name, commit it, tag it, and then build OTA versions for release. Please only use tags for OTA versions - or just don’t tag at all for the moment and let me maintain this. The last list of things I have for this build are: OTA via HTTP. SD CARD firmware updates seems to work fine today, as does serial flashing. I’ve still got to make the changes to HTTP firmware updates to use mongoose and support the new ESP IDF v2.1+ firmware arrangement of putting the checksum at the end of the firmware file. We need some simple high-level configs for auto-starting things. Stuff like vehicle type, whether the v2 server should auto-run, etc. Make it simpler for people to configure, without having to use scripts. This can be mapped to v2 protocol parameters/features. SPI RAM support and stability for v3.1 hardware (as well as compatibility with v3.0 hardware). Finalise the partition sizes. I think we can squeeze a bit more (maybe 3x 5MB firmwares, plus 512KB store?). End-User Documentation. Real-world stability (in cars). My concern is to have a relatively stable firmware that is usable for technically capable end-users in their cars, but also to have a way for them to simply update the firmware to keep pace with the fast release cycle we expect (at least in the coming months). Anything I’ve missed? Regards, Mark.
Mark, As I mentioned in an earlier email, the API for the function call to gather per-task heap allocation information has changed as part of the process of getting the feature added to the mainline. That change currently sits in the "review & merge queue" which is also subject to delay due to Chinese New Year. Would you like me to merge the code to openvehicles/esp-idf and openvehicles/Open-Vehicle-Monitoring-System-3 now? Presuming that the code is accepted after review and merged, I'm not sure what will happen when we merge that change in from the mainline at a future date. Angus said he "cherry-picked this and squashed the commits with a couple of minor tweaks for compilation warnings in certain configurations." This the merge might not go automatically. Also, I have not done anything to add (optional) immediate sending back into Mongoose. I have not heard of anyone hitting out-of-memory crashes when using SSH with a large burst of output, which is the concern that led me to make the change before when I hit the problem during debugging. Maybe with SPIRAM it is not an issue. SCP is already safe because it does one buffer at a time. -- Steve On Wed, 21 Feb 2018, Mark Webb-Johnson wrote:
My v3.1 test board seems stable, and we are ready for hardware production. I’m ordering the components with relatively long lead times (weeks) now, and the production order will go in as soon as China comes back from holiday (next week). First hardware batch will be available during March. I know lots of people are waiting for this, but I have to balance that against risk (should some hardware issue be found during wider real-world testing). I currently plan to order 120 modules (including 60 USA 3G modems, and 60 EU 3G modems) for the first batch. 100 will go to FastTech (for general ordering), and 20 to me (for special cases). As with OVMS v1, we’ll clearly say these are early units for ‘technically capable’ people, and the firmware still has a way to go.
On the firmware side, we need to move to a production style release cycle, and I will need to provide the first ‘factory’ firmware around the second week of March. Accordingly, I’m setting up some clean build environments and OTA release repositories (so I can cleanly build v3.0 and v3.1 firmware and have it available for OTA download).
I have created a changes.txt log file in the root of the project. I would appreciate it if those with commit access to master could update that file when they merge/commit changes to the project. The top of the file will contain an entry for the ‘next’ version, so the change text just needs to be added below that. When the version is ready to go, I will update changes.txt with the date and name, commit it, tag it, and then build OTA versions for release. Please only use tags for OTA versions - or just don’t tag at all for the moment and let me maintain this.
The last list of things I have for this build are:
OTA via HTTP. SD CARD firmware updates seems to work fine today, as does serial flashing. I’ve still got to make the changes to HTTP firmware updates to use mongoose and support the new ESP IDF v2.1+ firmware arrangement of putting the checksum at the end of the firmware file.
We need some simple high-level configs for auto-starting things. Stuff like vehicle type, whether the v2 server should auto-run, etc. Make it simpler for people to configure, without having to use scripts. This can be mapped to v2 protocol parameters/features.
SPI RAM support and stability for v3.1 hardware (as well as compatibility with v3.0 hardware).
Finalise the partition sizes. I think we can squeeze a bit more (maybe 3x 5MB firmwares, plus 512KB store?).
End-User Documentation.
Real-world stability (in cars).
My concern is to have a relatively stable firmware that is usable for technically capable end-users in their cars, but also to have a way for them to simply update the firmware to keep pace with the fast release cycle we expect (at least in the coming months).
Anything I’ve missed?
Regards, Mark.
Would you like me to merge the code to openvehicles/esp-idf and openvehicles/Open-Vehicle-Monitoring-System-3 now?
I don’t think we are in a hurry for this. What we have now works (since I updated our clone to latest espressif master and brought in their latest SPI RAM fixes). Can we just wait until it is accepted, and then deal with the merge then?
Also, I have not done anything to add (optional) immediate sending back into Mongoose.
That (mongoose) is on my list for moving to SPI RAM. That should reduce the impact of this. Not sure if we still need the immediate sending option. What do you think? If we do, it can be made to our clone of mongoose. Regards, Mark.
On 21 Feb 2018, at 10:52 AM, Stephen Casner <casner@acm.org> wrote:
Mark,
As I mentioned in an earlier email, the API for the function call to gather per-task heap allocation information has changed as part of the process of getting the feature added to the mainline. That change currently sits in the "review & merge queue" which is also subject to delay due to Chinese New Year.
Would you like me to merge the code to openvehicles/esp-idf and openvehicles/Open-Vehicle-Monitoring-System-3 now?
Presuming that the code is accepted after review and merged, I'm not sure what will happen when we merge that change in from the mainline at a future date. Angus said he "cherry-picked this and squashed the commits with a couple of minor tweaks for compilation warnings in certain configurations." This the merge might not go automatically.
Also, I have not done anything to add (optional) immediate sending back into Mongoose. I have not heard of anyone hitting out-of-memory crashes when using SSH with a large burst of output, which is the concern that led me to make the change before when I hit the problem during debugging. Maybe with SPIRAM it is not an issue. SCP is already safe because it does one buffer at a time.
-- Steve
On Wed, 21 Feb 2018, Mark Webb-Johnson wrote:
My v3.1 test board seems stable, and we are ready for hardware production. I’m ordering the components with relatively long lead times (weeks) now, and the production order will go in as soon as China comes back from holiday (next week). First hardware batch will be available during March. I know lots of people are waiting for this, but I have to balance that against risk (should some hardware issue be found during wider real-world testing). I currently plan to order 120 modules (including 60 USA 3G modems, and 60 EU 3G modems) for the first batch. 100 will go to FastTech (for general ordering), and 20 to me (for special cases). As with OVMS v1, we’ll clearly say these are early units for ‘technically capable’ people, and the firmware still has a way to go.
On the firmware side, we need to move to a production style release cycle, and I will need to provide the first ‘factory’ firmware around the second week of March. Accordingly, I’m setting up some clean build environments and OTA release repositories (so I can cleanly build v3.0 and v3.1 firmware and have it available for OTA download).
I have created a changes.txt log file in the root of the project. I would appreciate it if those with commit access to master could update that file when they merge/commit changes to the project. The top of the file will contain an entry for the ‘next’ version, so the change text just needs to be added below that. When the version is ready to go, I will update changes.txt with the date and name, commit it, tag it, and then build OTA versions for release. Please only use tags for OTA versions - or just don’t tag at all for the moment and let me maintain this.
The last list of things I have for this build are:
OTA via HTTP. SD CARD firmware updates seems to work fine today, as does serial flashing. I’ve still got to make the changes to HTTP firmware updates to use mongoose and support the new ESP IDF v2.1+ firmware arrangement of putting the checksum at the end of the firmware file.
We need some simple high-level configs for auto-starting things. Stuff like vehicle type, whether the v2 server should auto-run, etc. Make it simpler for people to configure, without having to use scripts. This can be mapped to v2 protocol parameters/features.
SPI RAM support and stability for v3.1 hardware (as well as compatibility with v3.0 hardware).
Finalise the partition sizes. I think we can squeeze a bit more (maybe 3x 5MB firmwares, plus 512KB store?).
End-User Documentation.
Real-world stability (in cars).
My concern is to have a relatively stable firmware that is usable for technically capable end-users in their cars, but also to have a way for them to simply update the firmware to keep pace with the fast release cycle we expect (at least in the coming months).
Anything I’ve missed?
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I can wait on these things. Tonight my PR got the "changes approved" checkmark. https://github.com/espressif/esp-idf/pull/1498#pullrequestreview-88994221 -- Steve On Wed, 21 Feb 2018, Mark Webb-Johnson wrote:
Would you like me to merge the code to openvehicles/esp-idf and openvehicles/Open-Vehicle-Monitoring-System-3 now?
I don't think we are in a hurry for this. What we have now works (since I updated our clone to latest espressif master and brought in their latest SPI RAM fixes).
Can we just wait until it is accepted, and then deal with the merge then?
Also, I have not done anything to add (optional) immediate sending back into Mongoose.
That (mongoose) is on my list for moving to SPI RAM. That should reduce the impact of this.
Not sure if we still need the immediate sending option. What do you think? If we do, it can be made to our clone of mongoose.
Regards, Mark.
On 21 Feb 2018, at 10:52 AM, Stephen Casner <casner@acm.org> wrote:
Mark,
As I mentioned in an earlier email, the API for the function call to gather per-task heap allocation information has changed as part of the process of getting the feature added to the mainline. That change currently sits in the "review & merge queue" which is also subject to delay due to Chinese New Year.
Would you like me to merge the code to openvehicles/esp-idf and openvehicles/Open-Vehicle-Monitoring-System-3 now?
Presuming that the code is accepted after review and merged, I'm not sure what will happen when we merge that change in from the mainline at a future date. Angus said he "cherry-picked this and squashed the commits with a couple of minor tweaks for compilation warnings in certain configurations." This the merge might not go automatically.
Also, I have not done anything to add (optional) immediate sending back into Mongoose. I have not heard of anyone hitting out-of-memory crashes when using SSH with a large burst of output, which is the concern that led me to make the change before when I hit the problem during debugging. Maybe with SPIRAM it is not an issue. SCP is already safe because it does one buffer at a time.
-- Steve
On Wed, 21 Feb 2018, Mark Webb-Johnson wrote:
My v3.1 test board seems stable, and we are ready for hardware production. I'm ordering the components with relatively long lead times (weeks) now, and the production order will go in as soon as China comes back from holiday (next week). First hardware batch will be available during March. I know lots of people are waiting for this, but I have to balance that against risk (should some hardware issue be found during wider real-world testing). I currently plan to order 120 modules (including 60 USA 3G modems, and 60 EU 3G modems) for the first batch. 100 will go to FastTech (for general ordering), and 20 to me (for special cases). As with OVMS v1, we'll clearly say these are early units for 'technically capable' people, and the firmware still has a way to go.
On the firmware side, we need to move to a production style release cycle, and I will need to provide the first 'factory' firmware around the second week of March. Accordingly, I'm setting up some clean build environments and OTA release repositories (so I can cleanly build v3.0 and v3.1 firmware and have it available for OTA download).
I have created a changes.txt log file in the root of the project. I would appreciate it if those with commit access to master could update that file when they merge/commit changes to the project. The top of the file will contain an entry for the 'next' version, so the change text just needs to be added below that. When the version is ready to go, I will update changes.txt with the date and name, commit it, tag it, and then build OTA versions for release. Please only use tags for OTA versions - or just don't tag at all for the moment and let me maintain this.
The last list of things I have for this build are:
OTA via HTTP. SD CARD firmware updates seems to work fine today, as does serial flashing. I've still got to make the changes to HTTP firmware updates to use mongoose and support the new ESP IDF v2.1+ firmware arrangement of putting the checksum at the end of the firmware file.
We need some simple high-level configs for auto-starting things. Stuff like vehicle type, whether the v2 server should auto-run, etc. Make it simpler for people to configure, without having to use scripts. This can be mapped to v2 protocol parameters/features.
SPI RAM support and stability for v3.1 hardware (as well as compatibility with v3.0 hardware).
Finalise the partition sizes. I think we can squeeze a bit more (maybe 3x 5MB firmwares, plus 512KB store?).
End-User Documentation.
Real-world stability (in cars).
My concern is to have a relatively stable firmware that is usable for technically capable end-users in their cars, but also to have a way for them to simply update the firmware to keep pace with the fast release cycle we expect (at least in the coming months).
Anything I've missed?
Regards, Mark.
My PR for heap task tracking has now been merged into espressif/esp-idf/master. Shall I merge to openvehicles/esp-idf/master and merge the corresponding update to ovms_module? Also, I have pushed a little cleanup commit. I assume that need not be mentioned in the changes.txt file. -- Steve On Tue, 20 Feb 2018, Stephen Casner wrote:
I can wait on these things. Tonight my PR got the "changes approved" checkmark.
https://github.com/espressif/esp-idf/pull/1498#pullrequestreview-88994221
-- Steve
On Wed, 21 Feb 2018, Mark Webb-Johnson wrote:
Would you like me to merge the code to openvehicles/esp-idf and openvehicles/Open-Vehicle-Monitoring-System-3 now?
I don't think we are in a hurry for this. What we have now works (since I updated our clone to latest espressif master and brought in their latest SPI RAM fixes).
Can we just wait until it is accepted, and then deal with the merge then?
Also, I have not done anything to add (optional) immediate sending back into Mongoose.
That (mongoose) is on my list for moving to SPI RAM. That should reduce the impact of this.
Not sure if we still need the immediate sending option. What do you think? If we do, it can be made to our clone of mongoose.
Regards, Mark.
On 21 Feb 2018, at 10:52 AM, Stephen Casner <casner@acm.org> wrote:
Mark,
As I mentioned in an earlier email, the API for the function call to gather per-task heap allocation information has changed as part of the process of getting the feature added to the mainline. That change currently sits in the "review & merge queue" which is also subject to delay due to Chinese New Year.
Would you like me to merge the code to openvehicles/esp-idf and openvehicles/Open-Vehicle-Monitoring-System-3 now?
Presuming that the code is accepted after review and merged, I'm not sure what will happen when we merge that change in from the mainline at a future date. Angus said he "cherry-picked this and squashed the commits with a couple of minor tweaks for compilation warnings in certain configurations." This the merge might not go automatically.
Also, I have not done anything to add (optional) immediate sending back into Mongoose. I have not heard of anyone hitting out-of-memory crashes when using SSH with a large burst of output, which is the concern that led me to make the change before when I hit the problem during debugging. Maybe with SPIRAM it is not an issue. SCP is already safe because it does one buffer at a time.
-- Steve
On Wed, 21 Feb 2018, Mark Webb-Johnson wrote:
My v3.1 test board seems stable, and we are ready for hardware production. I'm ordering the components with relatively long lead times (weeks) now, and the production order will go in as soon as China comes back from holiday (next week). First hardware batch will be available during March. I know lots of people are waiting for this, but I have to balance that against risk (should some hardware issue be found during wider real-world testing). I currently plan to order 120 modules (including 60 USA 3G modems, and 60 EU 3G modems) for the first batch. 100 will go to FastTech (for general ordering), and 20 to me (for special cases). As with OVMS v1, we'll clearly say these are early units for 'technically capable' people, and the firmware still has a way to go.
On the firmware side, we need to move to a production style release cycle, and I will need to provide the first 'factory' firmware around the second week of March. Accordingly, I'm setting up some clean build environments and OTA release repositories (so I can cleanly build v3.0 and v3.1 firmware and have it available for OTA download).
I have created a changes.txt log file in the root of the project. I would appreciate it if those with commit access to master could update that file when they merge/commit changes to the project. The top of the file will contain an entry for the 'next' version, so the change text just needs to be added below that. When the version is ready to go, I will update changes.txt with the date and name, commit it, tag it, and then build OTA versions for release. Please only use tags for OTA versions - or just don't tag at all for the moment and let me maintain this.
The last list of things I have for this build are:
OTA via HTTP. SD CARD firmware updates seems to work fine today, as does serial flashing. I've still got to make the changes to HTTP firmware updates to use mongoose and support the new ESP IDF v2.1+ firmware arrangement of putting the checksum at the end of the firmware file.
We need some simple high-level configs for auto-starting things. Stuff like vehicle type, whether the v2 server should auto-run, etc. Make it simpler for people to configure, without having to use scripts. This can be mapped to v2 protocol parameters/features.
SPI RAM support and stability for v3.1 hardware (as well as compatibility with v3.0 hardware).
Finalise the partition sizes. I think we can squeeze a bit more (maybe 3x 5MB firmwares, plus 512KB store?).
End-User Documentation.
Real-world stability (in cars).
My concern is to have a relatively stable firmware that is usable for technically capable end-users in their cars, but also to have a way for them to simply update the firmware to keep pace with the fast release cycle we expect (at least in the coming months).
Anything I've missed?
Regards, Mark.
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Ok. Got for it. Regards, Mark
On 24 Feb 2018, at 8:40 AM, Stephen Casner <casner@acm.org> wrote:
My PR for heap task tracking has now been merged into espressif/esp-idf/master. Shall I merge to openvehicles/esp-idf/master and merge the corresponding update to ovms_module?
Also, I have pushed a little cleanup commit. I assume that need not be mentioned in the changes.txt file.
-- Steve
On Tue, 20 Feb 2018, Stephen Casner wrote:
I can wait on these things. Tonight my PR got the "changes approved" checkmark.
https://github.com/espressif/esp-idf/pull/1498#pullrequestreview-88994221
-- Steve
On Wed, 21 Feb 2018, Mark Webb-Johnson wrote:
Would you like me to merge the code to openvehicles/esp-idf and openvehicles/Open-Vehicle-Monitoring-System-3 now?
I don't think we are in a hurry for this. What we have now works (since I updated our clone to latest espressif master and brought in their latest SPI RAM fixes).
Can we just wait until it is accepted, and then deal with the merge then?
Also, I have not done anything to add (optional) immediate sending back into Mongoose.
That (mongoose) is on my list for moving to SPI RAM. That should reduce the impact of this.
Not sure if we still need the immediate sending option. What do you think? If we do, it can be made to our clone of mongoose.
Regards, Mark.
On 21 Feb 2018, at 10:52 AM, Stephen Casner <casner@acm.org> wrote:
Mark,
As I mentioned in an earlier email, the API for the function call to gather per-task heap allocation information has changed as part of the process of getting the feature added to the mainline. That change currently sits in the "review & merge queue" which is also subject to delay due to Chinese New Year.
Would you like me to merge the code to openvehicles/esp-idf and openvehicles/Open-Vehicle-Monitoring-System-3 now?
Presuming that the code is accepted after review and merged, I'm not sure what will happen when we merge that change in from the mainline at a future date. Angus said he "cherry-picked this and squashed the commits with a couple of minor tweaks for compilation warnings in certain configurations." This the merge might not go automatically.
Also, I have not done anything to add (optional) immediate sending back into Mongoose. I have not heard of anyone hitting out-of-memory crashes when using SSH with a large burst of output, which is the concern that led me to make the change before when I hit the problem during debugging. Maybe with SPIRAM it is not an issue. SCP is already safe because it does one buffer at a time.
-- Steve
On Wed, 21 Feb 2018, Mark Webb-Johnson wrote:
My v3.1 test board seems stable, and we are ready for hardware production. I'm ordering the components with relatively long lead times (weeks) now, and the production order will go in as soon as China comes back from holiday (next week). First hardware batch will be available during March. I know lots of people are waiting for this, but I have to balance that against risk (should some hardware issue be found during wider real-world testing). I currently plan to order 120 modules (including 60 USA 3G modems, and 60 EU 3G modems) for the first batch. 100 will go to FastTech (for general ordering), and 20 to me (for special cases). As with OVMS v1, we'll clearly say these are early units for 'technically capable' people, and the firmware still has a way to go.
On the firmware side, we need to move to a production style release cycle, and I will need to provide the first 'factory' firmware around the second week of March. Accordingly, I'm setting up some clean build environments and OTA release repositories (so I can cleanly build v3.0 and v3.1 firmware and have it available for OTA download).
I have created a changes.txt log file in the root of the project. I would appreciate it if those with commit access to master could update that file when they merge/commit changes to the project. The top of the file will contain an entry for the 'next' version, so the change text just needs to be added below that. When the version is ready to go, I will update changes.txt with the date and name, commit it, tag it, and then build OTA versions for release. Please only use tags for OTA versions - or just don't tag at all for the moment and let me maintain this.
The last list of things I have for this build are:
OTA via HTTP. SD CARD firmware updates seems to work fine today, as does serial flashing. I've still got to make the changes to HTTP firmware updates to use mongoose and support the new ESP IDF v2.1+ firmware arrangement of putting the checksum at the end of the firmware file.
We need some simple high-level configs for auto-starting things. Stuff like vehicle type, whether the v2 server should auto-run, etc. Make it simpler for people to configure, without having to use scripts. This can be mapped to v2 protocol parameters/features.
SPI RAM support and stability for v3.1 hardware (as well as compatibility with v3.0 hardware).
Finalise the partition sizes. I think we can squeeze a bit more (maybe 3x 5MB firmwares, plus 512KB store?).
End-User Documentation.
Real-world stability (in cars).
My concern is to have a relatively stable firmware that is usable for technically capable end-users in their cars, but also to have a way for them to simply update the firmware to keep pace with the fast release cycle we expect (at least in the coming months).
Anything I've missed?
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
OK, I have merged the latest commits from espressif/esp-idf/master into our fork openvehicles/esp-idf/master and merged the corresponding update to ovms_module to match the changed API for getting per-task heap info. This means developers need to update both ESP IDF and OVMS v3 source trees (borrowing the lines from Mark's message about mDNS update): cd ~/esp/esp-idf git pull git submodule update cd ~/ovms/vehicle/OVMS.V3 git pull make (changing paths as appropriate) Also included is a fix for the "module tasks" command to show the stack size correctly again. That breakage was apparently caused by a change in the compiler behavior when espressif recently updated the toolchain for the esp-idf. -- Steve On Sat, 24 Feb 2018, Mark Webb-Johnson wrote:
Ok. Got for it.
Regards, Mark
On 24 Feb 2018, at 8:40 AM, Stephen Casner <casner@acm.org> wrote:
My PR for heap task tracking has now been merged into espressif/esp-idf/master. Shall I merge to openvehicles/esp-idf/master and merge the corresponding update to ovms_module?
Also, I have pushed a little cleanup commit. I assume that need not be mentioned in the changes.txt file.
-- Steve
On Tue, 20 Feb 2018, Stephen Casner wrote:
I can wait on these things. Tonight my PR got the "changes approved" checkmark.
https://github.com/espressif/esp-idf/pull/1498#pullrequestreview-88994221
-- Steve
On Wed, 21 Feb 2018, Mark Webb-Johnson wrote:
Would you like me to merge the code to openvehicles/esp-idf and openvehicles/Open-Vehicle-Monitoring-System-3 now?
I don't think we are in a hurry for this. What we have now works (since I updated our clone to latest espressif master and brought in their latest SPI RAM fixes).
Can we just wait until it is accepted, and then deal with the merge then?
Also, I have not done anything to add (optional) immediate sending back into Mongoose.
That (mongoose) is on my list for moving to SPI RAM. That should reduce the impact of this.
Not sure if we still need the immediate sending option. What do you think? If we do, it can be made to our clone of mongoose.
Regards, Mark.
On 21 Feb 2018, at 10:52 AM, Stephen Casner <casner@acm.org> wrote:
Mark,
As I mentioned in an earlier email, the API for the function call to gather per-task heap allocation information has changed as part of the process of getting the feature added to the mainline. That change currently sits in the "review & merge queue" which is also subject to delay due to Chinese New Year.
Would you like me to merge the code to openvehicles/esp-idf and openvehicles/Open-Vehicle-Monitoring-System-3 now?
Presuming that the code is accepted after review and merged, I'm not sure what will happen when we merge that change in from the mainline at a future date. Angus said he "cherry-picked this and squashed the commits with a couple of minor tweaks for compilation warnings in certain configurations." This the merge might not go automatically.
Also, I have not done anything to add (optional) immediate sending back into Mongoose. I have not heard of anyone hitting out-of-memory crashes when using SSH with a large burst of output, which is the concern that led me to make the change before when I hit the problem during debugging. Maybe with SPIRAM it is not an issue. SCP is already safe because it does one buffer at a time.
-- Steve
On Wed, 21 Feb 2018, Mark Webb-Johnson wrote:
My v3.1 test board seems stable, and we are ready for hardware production. I'm ordering the components with relatively long lead times (weeks) now, and the production order will go in as soon as China comes back from holiday (next week). First hardware batch will be available during March. I know lots of people are waiting for this, but I have to balance that against risk (should some hardware issue be found during wider real-world testing). I currently plan to order 120 modules (including 60 USA 3G modems, and 60 EU 3G modems) for the first batch. 100 will go to FastTech (for general ordering), and 20 to me (for special cases). As with OVMS v1, we'll clearly say these are early units for 'technically capable' people, and the firmware still has a way to go.
On the firmware side, we need to move to a production style release cycle, and I will need to provide the first 'factory' firmware around the second week of March. Accordingly, I'm setting up some clean build environments and OTA release repositories (so I can cleanly build v3.0 and v3.1 firmware and have it available for OTA download).
I have created a changes.txt log file in the root of the project. I would appreciate it if those with commit access to master could update that file when they merge/commit changes to the project. The top of the file will contain an entry for the 'next' version, so the change text just needs to be added below that. When the version is ready to go, I will update changes.txt with the date and name, commit it, tag it, and then build OTA versions for release. Please only use tags for OTA versions - or just don't tag at all for the moment and let me maintain this.
The last list of things I have for this build are:
OTA via HTTP. SD CARD firmware updates seems to work fine today, as does serial flashing. I've still got to make the changes to HTTP firmware updates to use mongoose and support the new ESP IDF v2.1+ firmware arrangement of putting the checksum at the end of the firmware file.
We need some simple high-level configs for auto-starting things. Stuff like vehicle type, whether the v2 server should auto-run, etc. Make it simpler for people to configure, without having to use scripts. This can be mapped to v2 protocol parameters/features.
SPI RAM support and stability for v3.1 hardware (as well as compatibility with v3.0 hardware).
Finalise the partition sizes. I think we can squeeze a bit more (maybe 3x 5MB firmwares, plus 512KB store?).
End-User Documentation.
Real-world stability (in cars).
My concern is to have a relatively stable firmware that is usable for technically capable end-users in their cars, but also to have a way for them to simply update the firmware to keep pace with the fast release cycle we expect (at least in the coming months).
Anything I've missed?
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
Builds and compiles for me. Happy to see this integrated to ESP IDF mainline. Regards, Mark.
On 24 Feb 2018, at 4:10 PM, Stephen Casner <casner@acm.org> wrote:
OK, I have merged the latest commits from espressif/esp-idf/master into our fork openvehicles/esp-idf/master and merged the corresponding update to ovms_module to match the changed API for getting per-task heap info.
This means developers need to update both ESP IDF and OVMS v3 source trees (borrowing the lines from Mark's message about mDNS update):
cd ~/esp/esp-idf git pull git submodule update
cd ~/ovms/vehicle/OVMS.V3 git pull make
(changing paths as appropriate)
Also included is a fix for the "module tasks" command to show the stack size correctly again. That breakage was apparently caused by a change in the compiler behavior when espressif recently updated the toolchain for the esp-idf.
-- Steve
On Sat, 24 Feb 2018, Mark Webb-Johnson wrote:
Ok. Got for it.
Regards, Mark
On 24 Feb 2018, at 8:40 AM, Stephen Casner <casner@acm.org> wrote:
My PR for heap task tracking has now been merged into espressif/esp-idf/master. Shall I merge to openvehicles/esp-idf/master and merge the corresponding update to ovms_module?
Also, I have pushed a little cleanup commit. I assume that need not be mentioned in the changes.txt file.
-- Steve
On Tue, 20 Feb 2018, Stephen Casner wrote:
I can wait on these things. Tonight my PR got the "changes approved" checkmark.
https://github.com/espressif/esp-idf/pull/1498#pullrequestreview-88994221
-- Steve
On Wed, 21 Feb 2018, Mark Webb-Johnson wrote:
Would you like me to merge the code to openvehicles/esp-idf and openvehicles/Open-Vehicle-Monitoring-System-3 now?
I don't think we are in a hurry for this. What we have now works (since I updated our clone to latest espressif master and brought in their latest SPI RAM fixes).
Can we just wait until it is accepted, and then deal with the merge then?
Also, I have not done anything to add (optional) immediate sending back into Mongoose.
That (mongoose) is on my list for moving to SPI RAM. That should reduce the impact of this.
Not sure if we still need the immediate sending option. What do you think? If we do, it can be made to our clone of mongoose.
Regards, Mark.
On 21 Feb 2018, at 10:52 AM, Stephen Casner <casner@acm.org> wrote:
Mark,
As I mentioned in an earlier email, the API for the function call to gather per-task heap allocation information has changed as part of the process of getting the feature added to the mainline. That change currently sits in the "review & merge queue" which is also subject to delay due to Chinese New Year.
Would you like me to merge the code to openvehicles/esp-idf and openvehicles/Open-Vehicle-Monitoring-System-3 now?
Presuming that the code is accepted after review and merged, I'm not sure what will happen when we merge that change in from the mainline at a future date. Angus said he "cherry-picked this and squashed the commits with a couple of minor tweaks for compilation warnings in certain configurations." This the merge might not go automatically.
Also, I have not done anything to add (optional) immediate sending back into Mongoose. I have not heard of anyone hitting out-of-memory crashes when using SSH with a large burst of output, which is the concern that led me to make the change before when I hit the problem during debugging. Maybe with SPIRAM it is not an issue. SCP is already safe because it does one buffer at a time.
-- Steve
> On Wed, 21 Feb 2018, Mark Webb-Johnson wrote: > > > My v3.1 test board seems stable, and we are ready for hardware production. I'm ordering the components with relatively long lead times (weeks) now, and the production order will go in as soon as China comes back from holiday (next week). First hardware batch will be available during March. I know lots of people are waiting for this, but I have to balance that against risk (should some hardware issue be found during wider real-world testing). I currently plan to order 120 modules (including 60 USA 3G modems, and 60 EU 3G modems) for the first batch. 100 will go to FastTech (for general ordering), and 20 to me (for special cases). As with OVMS v1, we'll clearly say these are early units for 'technically capable' people, and the firmware still has a way to go. > > On the firmware side, we need to move to a production style release cycle, and I will need to provide the first 'factory' firmware around the second week of March. Accordingly, I'm setting up some clean build environments and OTA release repositories (so I can cleanly build v3.0 and v3.1 firmware and have it available for OTA download). > > I have created a changes.txt log file in the root of the project. I would appreciate it if those with commit access to master could update that file when they merge/commit changes to the project. The top of the file will contain an entry for the 'next' version, so the change text just needs to be added below that. When the version is ready to go, I will update changes.txt with the date and name, commit it, tag it, and then build OTA versions for release. Please only use tags for OTA versions - or just don't tag at all for the moment and let me maintain this. > > The last list of things I have for this build are: > > OTA via HTTP. SD CARD firmware updates seems to work fine today, as does serial flashing. I've still got to make the changes to HTTP firmware updates to use mongoose and support the new ESP IDF v2.1+ firmware arrangement of putting the checksum at the end of the firmware file. > > We need some simple high-level configs for auto-starting things. Stuff like vehicle type, whether the v2 server should auto-run, etc. Make it simpler for people to configure, without having to use scripts. This can be mapped to v2 protocol parameters/features. > > SPI RAM support and stability for v3.1 hardware (as well as compatibility with v3.0 hardware). > > Finalise the partition sizes. I think we can squeeze a bit more (maybe 3x 5MB firmwares, plus 512KB store?). > > End-User Documentation. > > Real-world stability (in cars). > > My concern is to have a relatively stable firmware that is usable for technically capable end-users in their cars, but also to have a way for them to simply update the firmware to keep pace with the fast release cycle we expect (at least in the coming months). > > Anything I've missed? > > 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
Is there a specific requirement for the findcp2102 tool? balzer@leela:~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3> make Traceback (most recent call last): File "/home/balzer/esp/esp-idf/tools/findcp2102.py", line 47, in <module> pl.sort(key=lambda x: x.location, reverse=False) File "/home/balzer/esp/esp-idf/tools/findcp2102.py", line 47, in <lambda> pl.sort(key=lambda x: x.location, reverse=False) AttributeError: 'tuple' object has no attribute 'location' balzer@leela:~/esp/esp-idf> python -m serial.tools.list_ports -v "USB VID:PID=10c4:ea60" Filtered list with regexp: 'USB VID:PID=10c4:ea60' /dev/ttyUSB0 desc: Silicon Labs CP2102 USB to UART Bridge Controller 0001 hwid: USB VID:PID=10c4:ea60 SNR=0001 1 ports found balzer@leela:~/esp/esp-idf> python --version Python 2.7.12 leela:~ # pip freeze | grep -i serial pyserial==3.4 I've tried running it with python3.4, but that throws syntax errors. Michael Am 24.02.2018 um 09:10 schrieb Stephen Casner:
OK, I have merged the latest commits from espressif/esp-idf/master into our fork openvehicles/esp-idf/master and merged the corresponding update to ovms_module to match the changed API for getting per-task heap info.
This means developers need to update both ESP IDF and OVMS v3 source trees (borrowing the lines from Mark's message about mDNS update):
cd ~/esp/esp-idf git pull git submodule update
cd ~/ovms/vehicle/OVMS.V3 git pull make
(changing paths as appropriate)
Also included is a fix for the "module tasks" command to show the stack size correctly again. That breakage was apparently caused by a change in the compiler behavior when espressif recently updated the toolchain for the esp-idf.
-- Steve
On Sat, 24 Feb 2018, Mark Webb-Johnson wrote:
Ok. Got for it.
Regards, Mark
On 24 Feb 2018, at 8:40 AM, Stephen Casner <casner@acm.org> wrote:
My PR for heap task tracking has now been merged into espressif/esp-idf/master. Shall I merge to openvehicles/esp-idf/master and merge the corresponding update to ovms_module?
Also, I have pushed a little cleanup commit. I assume that need not be mentioned in the changes.txt file.
-- Steve
On Tue, 20 Feb 2018, Stephen Casner wrote:
I can wait on these things. Tonight my PR got the "changes approved" checkmark.
https://github.com/espressif/esp-idf/pull/1498#pullrequestreview-88994221
-- Steve
On Wed, 21 Feb 2018, Mark Webb-Johnson wrote:
Would you like me to merge the code to openvehicles/esp-idf and openvehicles/Open-Vehicle-Monitoring-System-3 now? I don't think we are in a hurry for this. What we have now works (since I updated our clone to latest espressif master and brought in their latest SPI RAM fixes).
Can we just wait until it is accepted, and then deal with the merge then?
Also, I have not done anything to add (optional) immediate sending back into Mongoose. That (mongoose) is on my list for moving to SPI RAM. That should reduce the impact of this.
Not sure if we still need the immediate sending option. What do you think? If we do, it can be made to our clone of mongoose.
Regards, Mark.
On 21 Feb 2018, at 10:52 AM, Stephen Casner <casner@acm.org> wrote:
Mark,
As I mentioned in an earlier email, the API for the function call to gather per-task heap allocation information has changed as part of the process of getting the feature added to the mainline. That change currently sits in the "review & merge queue" which is also subject to delay due to Chinese New Year.
Would you like me to merge the code to openvehicles/esp-idf and openvehicles/Open-Vehicle-Monitoring-System-3 now?
Presuming that the code is accepted after review and merged, I'm not sure what will happen when we merge that change in from the mainline at a future date. Angus said he "cherry-picked this and squashed the commits with a couple of minor tweaks for compilation warnings in certain configurations." This the merge might not go automatically.
Also, I have not done anything to add (optional) immediate sending back into Mongoose. I have not heard of anyone hitting out-of-memory crashes when using SSH with a large burst of output, which is the concern that led me to make the change before when I hit the problem during debugging. Maybe with SPIRAM it is not an issue. SCP is already safe because it does one buffer at a time.
-- Steve
> On Wed, 21 Feb 2018, Mark Webb-Johnson wrote: > > > My v3.1 test board seems stable, and we are ready for hardware production. I'm ordering the components with relatively long lead times (weeks) now, and the production order will go in as soon as China comes back from holiday (next week). First hardware batch will be available during March. I know lots of people are waiting for this, but I have to balance that against risk (should some hardware issue be found during wider real-world testing). I currently plan to order 120 modules (including 60 USA 3G modems, and 60 EU 3G modems) for the first batch. 100 will go to FastTech (for general ordering), and 20 to me (for special cases). As with OVMS v1, we'll clearly say these are early units for 'technically capable' people, and the firmware still has a way to go. > > On the firmware side, we need to move to a production style release cycle, and I will need to provide the first 'factory' firmware around the second week of March. Accordingly, I'm setting up some clean build environments and OTA release repositories (so I can cleanly build v3.0 and v3.1 firmware and have it available for OTA download). > > I have created a changes.txt log file in the root of the project. I would appreciate it if those with commit access to master could update that file when they merge/commit changes to the project. The top of the file will contain an entry for the 'next' version, so the change text just needs to be added below that. When the version is ready to go, I will update changes.txt with the date and name, commit it, tag it, and then build OTA versions for release. Please only use tags for OTA versions - or just don't tag at all for the moment and let me maintain this. > > The last list of things I have for this build are: > > OTA via HTTP. SD CARD firmware updates seems to work fine today, as does serial flashing. I've still got to make the changes to HTTP firmware updates to use mongoose and support the new ESP IDF v2.1+ firmware arrangement of putting the checksum at the end of the firmware file. > > We need some simple high-level configs for auto-starting things. Stuff like vehicle type, whether the v2 server should auto-run, etc. Make it simpler for people to configure, without having to use scripts. This can be mapped to v2 protocol parameters/features. > > SPI RAM support and stability for v3.1 hardware (as well as compatibility with v3.0 hardware). > > Finalise the partition sizes. I think we can squeeze a bit more (maybe 3x 5MB firmwares, plus 512KB store?). > > End-User Documentation. > > Real-world stability (in cars). > > My concern is to have a relatively stable firmware that is usable for technically capable end-users in their cars, but also to have a way for them to simply update the firmware to keep pace with the fast release cycle we expect (at least in the coming months). > > Anything I've missed? > > 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
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Something's wrong with my python setup. The documentation says pyserial changed from tuples to objects in version 3, I've got 3.4 and apparently still get tuples. I remember doing an update on pyserial in order to get miniterm running. The update didn't help but seemed to be successfull. I now think it actually wasn't. Time for a reinstall… Am 24.02.2018 um 10:45 schrieb Michael Balzer:
Is there a specific requirement for the findcp2102 tool?
balzer@leela:~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3> make Traceback (most recent call last): File "/home/balzer/esp/esp-idf/tools/findcp2102.py", line 47, in <module> pl.sort(key=lambda x: x.location, reverse=False) File "/home/balzer/esp/esp-idf/tools/findcp2102.py", line 47, in <lambda> pl.sort(key=lambda x: x.location, reverse=False) AttributeError: 'tuple' object has no attribute 'location'
balzer@leela:~/esp/esp-idf> python -m serial.tools.list_ports -v "USB VID:PID=10c4:ea60" Filtered list with regexp: 'USB VID:PID=10c4:ea60' /dev/ttyUSB0 desc: Silicon Labs CP2102 USB to UART Bridge Controller 0001 hwid: USB VID:PID=10c4:ea60 SNR=0001 1 ports found
balzer@leela:~/esp/esp-idf> python --version Python 2.7.12
leela:~ # pip freeze | grep -i serial pyserial==3.4
I've tried running it with python3.4, but that throws syntax errors.
Michael
Am 24.02.2018 um 09:10 schrieb Stephen Casner:
OK, I have merged the latest commits from espressif/esp-idf/master into our fork openvehicles/esp-idf/master and merged the corresponding update to ovms_module to match the changed API for getting per-task heap info.
This means developers need to update both ESP IDF and OVMS v3 source trees (borrowing the lines from Mark's message about mDNS update):
cd ~/esp/esp-idf git pull git submodule update
cd ~/ovms/vehicle/OVMS.V3 git pull make
(changing paths as appropriate)
Also included is a fix for the "module tasks" command to show the stack size correctly again. That breakage was apparently caused by a change in the compiler behavior when espressif recently updated the toolchain for the esp-idf.
-- Steve
On Sat, 24 Feb 2018, Mark Webb-Johnson wrote:
Ok. Got for it.
Regards, Mark
On 24 Feb 2018, at 8:40 AM, Stephen Casner <casner@acm.org> wrote:
My PR for heap task tracking has now been merged into espressif/esp-idf/master. Shall I merge to openvehicles/esp-idf/master and merge the corresponding update to ovms_module?
Also, I have pushed a little cleanup commit. I assume that need not be mentioned in the changes.txt file.
-- Steve
On Tue, 20 Feb 2018, Stephen Casner wrote:
I can wait on these things. Tonight my PR got the "changes approved" checkmark.
https://github.com/espressif/esp-idf/pull/1498#pullrequestreview-88994221
-- Steve
On Wed, 21 Feb 2018, Mark Webb-Johnson wrote:
> Would you like me to merge the code to openvehicles/esp-idf and > openvehicles/Open-Vehicle-Monitoring-System-3 now? I don't think we are in a hurry for this. What we have now works (since I updated our clone to latest espressif master and brought in their latest SPI RAM fixes).
Can we just wait until it is accepted, and then deal with the merge then?
> Also, I have not done anything to add (optional) immediate sending > back into Mongoose. That (mongoose) is on my list for moving to SPI RAM. That should reduce the impact of this.
Not sure if we still need the immediate sending option. What do you think? If we do, it can be made to our clone of mongoose.
Regards, Mark.
> On 21 Feb 2018, at 10:52 AM, Stephen Casner <casner@acm.org> wrote: > > Mark, > > As I mentioned in an earlier email, the API for the function call to > gather per-task heap allocation information has changed as part of the > process of getting the feature added to the mainline. That change > currently sits in the "review & merge queue" which is also subject to > delay due to Chinese New Year. > > Would you like me to merge the code to openvehicles/esp-idf and > openvehicles/Open-Vehicle-Monitoring-System-3 now? > > Presuming that the code is accepted after review and merged, I'm not > sure what will happen when we merge that change in from the mainline > at a future date. Angus said he "cherry-picked this and squashed the > commits with a couple of minor tweaks for compilation warnings in > certain configurations." This the merge might not go automatically. > > Also, I have not done anything to add (optional) immediate sending > back into Mongoose. I have not heard of anyone hitting out-of-memory > crashes when using SSH with a large burst of output, which is the > concern that led me to make the change before when I hit the problem > during debugging. Maybe with SPIRAM it is not an issue. SCP is > already safe because it does one buffer at a time. > > -- Steve > >> On Wed, 21 Feb 2018, Mark Webb-Johnson wrote: >> >> >> My v3.1 test board seems stable, and we are ready for hardware production. I'm ordering the components with relatively long lead times (weeks) now, and the production order will go in as soon as China comes back from holiday (next week). First hardware batch will be available during March. I know lots of people are waiting for this, but I have to balance that against risk (should some hardware issue be found during wider real-world testing). I currently plan to order 120 modules (including 60 USA 3G modems, and 60 EU 3G modems) for the first batch. 100 will go to FastTech (for general ordering), and 20 to me (for special cases). As with OVMS v1, we'll clearly say these are early units for 'technically capable' people, and the firmware still has a way to go. >> >> On the firmware side, we need to move to a production style release cycle, and I will need to provide the first 'factory' firmware around the second week of March. Accordingly, I'm setting up some clean build environments and OTA release repositories (so I can cleanly build v3.0 and v3.1 firmware and have it available for OTA download). >> >> I have created a changes.txt log file in the root of the project. I would appreciate it if those with commit access to master could update that file when they merge/commit changes to the project. The top of the file will contain an entry for the 'next' version, so the change text just needs to be added below that. When the version is ready to go, I will update changes.txt with the date and name, commit it, tag it, and then build OTA versions for release. Please only use tags for OTA versions - or just don't tag at all for the moment and let me maintain this. >> >> The last list of things I have for this build are: >> >> OTA via HTTP. SD CARD firmware updates seems to work fine today, as does serial flashing. I've still got to make the changes to HTTP firmware updates to use mongoose and support the new ESP IDF v2.1+ firmware arrangement of putting the checksum at the end of the firmware file. >> >> We need some simple high-level configs for auto-starting things. Stuff like vehicle type, whether the v2 server should auto-run, etc. Make it simpler for people to configure, without having to use scripts. This can be mapped to v2 protocol parameters/features. >> >> SPI RAM support and stability for v3.1 hardware (as well as compatibility with v3.0 hardware). >> >> Finalise the partition sizes. I think we can squeeze a bit more (maybe 3x 5MB firmwares, plus 512KB store?). >> >> End-User Documentation. >> >> Real-world stability (in cars). >> >> My concern is to have a relatively stable firmware that is usable for technically capable end-users in their cars, but also to have a way for them to simply update the firmware to keep pace with the fast release cycle we expect (at least in the coming months). >> >> Anything I've missed? >> >> 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
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Michael, I hope you have figured out your python version. Indeed the findcp2102.py code has a dependency on version 3, but since there was a check elsewhere in the esp-idf make process already I figured this was safe. -- Steve On Sat, 24 Feb 2018, Michael Balzer wrote:
Something's wrong with my python setup. The documentation says pyserial changed from tuples to objects in version 3, I've got 3.4 and apparently still get tuples.
I remember doing an update on pyserial in order to get miniterm running. The update didn't help but seemed to be successfull. I now think it actually wasn't.
Time for a reinstall...
Am 24.02.2018 um 10:45 schrieb Michael Balzer:
Is there a specific requirement for the findcp2102 tool?
balzer@leela:~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3> make Traceback (most recent call last): File "/home/balzer/esp/esp-idf/tools/findcp2102.py", line 47, in <module> pl.sort(key=lambda x: x.location, reverse=False) File "/home/balzer/esp/esp-idf/tools/findcp2102.py", line 47, in <lambda> pl.sort(key=lambda x: x.location, reverse=False) AttributeError: 'tuple' object has no attribute 'location'
balzer@leela:~/esp/esp-idf> python -m serial.tools.list_ports -v "USB VID:PID=10c4:ea60" Filtered list with regexp: 'USB VID:PID=10c4:ea60' /dev/ttyUSB0 desc: Silicon Labs CP2102 USB to UART Bridge Controller 0001 hwid: USB VID:PID=10c4:ea60 SNR=0001 1 ports found
balzer@leela:~/esp/esp-idf> python --version Python 2.7.12
leela:~ # pip freeze | grep -i serial pyserial==3.4
I've tried running it with python3.4, but that throws syntax errors.
Michael
Am 24.02.2018 um 09:10 schrieb Stephen Casner:
OK, I have merged the latest commits from espressif/esp-idf/master into our fork openvehicles/esp-idf/master and merged the corresponding update to ovms_module to match the changed API for getting per-task heap info.
This means developers need to update both ESP IDF and OVMS v3 source trees (borrowing the lines from Mark's message about mDNS update):
cd ~/esp/esp-idf git pull git submodule update
cd ~/ovms/vehicle/OVMS.V3 git pull make
(changing paths as appropriate)
Also included is a fix for the "module tasks" command to show the stack size correctly again. That breakage was apparently caused by a change in the compiler behavior when espressif recently updated the toolchain for the esp-idf.
-- Steve
On Sat, 24 Feb 2018, Mark Webb-Johnson wrote:
Ok. Got for it.
Regards, Mark
On 24 Feb 2018, at 8:40 AM, Stephen Casner <casner@acm.org> wrote:
My PR for heap task tracking has now been merged into espressif/esp-idf/master. Shall I merge to openvehicles/esp-idf/master and merge the corresponding update to ovms_module?
Also, I have pushed a little cleanup commit. I assume that need not be mentioned in the changes.txt file.
-- Steve
On Tue, 20 Feb 2018, Stephen Casner wrote:
I can wait on these things. Tonight my PR got the "changes approved" checkmark.
https://github.com/espressif/esp-idf/pull/1498#pullrequestreview-88994221
-- Steve
On Wed, 21 Feb 2018, Mark Webb-Johnson wrote:
>> Would you like me to merge the code to openvehicles/esp-idf and >> openvehicles/Open-Vehicle-Monitoring-System-3 now? > I don't think we are in a hurry for this. What we have now works (since I updated our clone to latest espressif master and brought in their latest SPI RAM fixes). > > Can we just wait until it is accepted, and then deal with the merge then? > >> Also, I have not done anything to add (optional) immediate sending >> back into Mongoose. > That (mongoose) is on my list for moving to SPI RAM. That should reduce the impact of this. > > Not sure if we still need the immediate sending option. What do you think? If we do, it can be made to our clone of mongoose. > > Regards, Mark. > >> On 21 Feb 2018, at 10:52 AM, Stephen Casner <casner@acm.org> wrote: >> >> Mark, >> >> As I mentioned in an earlier email, the API for the function call to >> gather per-task heap allocation information has changed as part of the >> process of getting the feature added to the mainline. That change >> currently sits in the "review & merge queue" which is also subject to >> delay due to Chinese New Year. >> >> Would you like me to merge the code to openvehicles/esp-idf and >> openvehicles/Open-Vehicle-Monitoring-System-3 now? >> >> Presuming that the code is accepted after review and merged, I'm not >> sure what will happen when we merge that change in from the mainline >> at a future date. Angus said he "cherry-picked this and squashed the >> commits with a couple of minor tweaks for compilation warnings in >> certain configurations." This the merge might not go automatically. >> >> Also, I have not done anything to add (optional) immediate sending >> back into Mongoose. I have not heard of anyone hitting out-of-memory >> crashes when using SSH with a large burst of output, which is the >> concern that led me to make the change before when I hit the problem >> during debugging. Maybe with SPIRAM it is not an issue. SCP is >> already safe because it does one buffer at a time. >> >> -- Steve >> >>> On Wed, 21 Feb 2018, Mark Webb-Johnson wrote: >>> >>> >>> My v3.1 test board seems stable, and we are ready for hardware production. I'm ordering the components with relatively long lead times (weeks) now, and the production order will go in as soon as China comes back from holiday (next week). First hardware batch will be available during March. I know lots of people are waiting for this, but I have to balance that against risk (should some hardware issue be found during wider real-world testing). I currently plan to order 120 modules (including 60 USA 3G modems, and 60 EU 3G modems) for the first batch. 100 will go to FastTech (for general ordering), and 20 to me (for special cases). As with OVMS v1, we'll clearly say these are early units for 'technically capable' people, and the firmware still has a way to go. >>> >>> On the firmware side, we need to move to a production style release cycle, and I will need to provide the first 'factory' firmware around the second week of March. Accordingly, I'm setting up some clean build environments and OTA release repositories (so I can cleanly build v3.0 and v3.1 firmware and have it available for OTA download). >>> >>> I have created a changes.txt log file in the root of the project. I would appreciate it if those with commit access to master could update that file when they merge/commit changes to the project. The top of the file will contain an entry for the 'next' version, so the change text just needs to be added below that. When the version is ready to go, I will update changes.txt with the date and name, commit it, tag it, and then build OTA versions for release. Please only use tags for OTA versions - or just don't tag at all for the moment and let me maintain this. >>> >>> The last list of things I have for this build are: >>> >>> OTA via HTTP. SD CARD firmware updates seems to work fine today, as does serial flashing. I've still got to make the changes to HTTP firmware updates to use mongoose and support the new ESP IDF v2.1+ firmware arrangement of putting the checksum at the end of the firmware file. >>> >>> We need some simple high-level configs for auto-starting things. Stuff like vehicle type, whether the v2 server should auto-run, etc. Make it simpler for people to configure, without having to use scripts. This can be mapped to v2 protocol parameters/features. >>> >>> SPI RAM support and stability for v3.1 hardware (as well as compatibility with v3.0 hardware). >>> >>> Finalise the partition sizes. I think we can squeeze a bit more (maybe 3x 5MB firmwares, plus 512KB store?). >>> >>> End-User Documentation. >>> >>> Real-world stability (in cars). >>> >>> My concern is to have a relatively stable firmware that is usable for technically capable end-users in their cars, but also to have a way for them to simply update the firmware to keep pace with the fast release cycle we expect (at least in the coming months). >>> >>> Anything I've missed? >>> >>> 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
-- 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
Stephen, today I've learned something about python… ;) My distribution (openSuSE 42.3) still uses python2 as the base version, and python3 is also installed to enable transition. I thought I had installed pyserial-3.4 by doing "pip install --uprade pyserial" -- because it told me I had done so: leela:~ # pip install --upgrade pyserial Collecting pyserial Using cached pyserial-3.4-py2.py3-none-any.whl Installing collected packages: pyserial Uninstalling pyserial-2.7: Successfully uninstalled pyserial-2.7 Successfully installed pyserial-3.4 But it now turned out it only installed the update for the python3 environment, while python2 still used pyserial 2.7. Apparently "pip" is only installed for the python3 environment. After doing a manual update on the python2 pyserial package, the script now works. So for anyone with a similar setup/issue, do this: - download the tar.gz from https://pypi.python.org/pypi/pyserial - tar xzf pyserial-3.4.tar.gz - cd pyserial-3.4 - python setup.py install "make monitor" now also works. Btw: according to… https://stackoverflow.com/questions/6908143/should-i-put-shebang-in-python-s... …the shebang "#!/usr/bin/env python" should not be used. Regards, Michael Am 24.02.2018 um 17:58 schrieb Stephen Casner:
Michael,
I hope you have figured out your python version. Indeed the findcp2102.py code has a dependency on version 3, but since there was a check elsewhere in the esp-idf make process already I figured this was safe.
-- Steve
On Sat, 24 Feb 2018, Michael Balzer wrote:
Something's wrong with my python setup. The documentation says pyserial changed from tuples to objects in version 3, I've got 3.4 and apparently still get tuples.
I remember doing an update on pyserial in order to get miniterm running. The update didn't help but seemed to be successfull. I now think it actually wasn't.
Time for a reinstall...
Am 24.02.2018 um 10:45 schrieb Michael Balzer:
Is there a specific requirement for the findcp2102 tool?
balzer@leela:~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3> make Traceback (most recent call last): File "/home/balzer/esp/esp-idf/tools/findcp2102.py", line 47, in <module> pl.sort(key=lambda x: x.location, reverse=False) File "/home/balzer/esp/esp-idf/tools/findcp2102.py", line 47, in <lambda> pl.sort(key=lambda x: x.location, reverse=False) AttributeError: 'tuple' object has no attribute 'location'
balzer@leela:~/esp/esp-idf> python -m serial.tools.list_ports -v "USB VID:PID=10c4:ea60" Filtered list with regexp: 'USB VID:PID=10c4:ea60' /dev/ttyUSB0 desc: Silicon Labs CP2102 USB to UART Bridge Controller 0001 hwid: USB VID:PID=10c4:ea60 SNR=0001 1 ports found
balzer@leela:~/esp/esp-idf> python --version Python 2.7.12
leela:~ # pip freeze | grep -i serial pyserial==3.4
I've tried running it with python3.4, but that throws syntax errors.
Michael
Am 24.02.2018 um 09:10 schrieb Stephen Casner:
OK, I have merged the latest commits from espressif/esp-idf/master into our fork openvehicles/esp-idf/master and merged the corresponding update to ovms_module to match the changed API for getting per-task heap info.
This means developers need to update both ESP IDF and OVMS v3 source trees (borrowing the lines from Mark's message about mDNS update):
cd ~/esp/esp-idf git pull git submodule update
cd ~/ovms/vehicle/OVMS.V3 git pull make
(changing paths as appropriate)
Also included is a fix for the "module tasks" command to show the stack size correctly again. That breakage was apparently caused by a change in the compiler behavior when espressif recently updated the toolchain for the esp-idf.
-- Steve
On Sat, 24 Feb 2018, Mark Webb-Johnson wrote:
Ok. Got for it.
Regards, Mark
On 24 Feb 2018, at 8:40 AM, Stephen Casner <casner@acm.org> wrote:
My PR for heap task tracking has now been merged into espressif/esp-idf/master. Shall I merge to openvehicles/esp-idf/master and merge the corresponding update to ovms_module?
Also, I have pushed a little cleanup commit. I assume that need not be mentioned in the changes.txt file.
-- Steve
> On Tue, 20 Feb 2018, Stephen Casner wrote: > > I can wait on these things. Tonight my PR got the "changes approved" > checkmark. > > https://github.com/espressif/esp-idf/pull/1498#pullrequestreview-88994221 > > -- Steve > > On Wed, 21 Feb 2018, Mark Webb-Johnson wrote: > >>> Would you like me to merge the code to openvehicles/esp-idf and >>> openvehicles/Open-Vehicle-Monitoring-System-3 now? >> I don't think we are in a hurry for this. What we have now works (since I updated our clone to latest espressif master and brought in their latest SPI RAM fixes). >> >> Can we just wait until it is accepted, and then deal with the merge then? >> >>> Also, I have not done anything to add (optional) immediate sending >>> back into Mongoose. >> That (mongoose) is on my list for moving to SPI RAM. That should reduce the impact of this. >> >> Not sure if we still need the immediate sending option. What do you think? If we do, it can be made to our clone of mongoose. >> >> Regards, Mark. >> >>> On 21 Feb 2018, at 10:52 AM, Stephen Casner <casner@acm.org> wrote: >>> >>> Mark, >>> >>> As I mentioned in an earlier email, the API for the function call to >>> gather per-task heap allocation information has changed as part of the >>> process of getting the feature added to the mainline. That change >>> currently sits in the "review & merge queue" which is also subject to >>> delay due to Chinese New Year. >>> >>> Would you like me to merge the code to openvehicles/esp-idf and >>> openvehicles/Open-Vehicle-Monitoring-System-3 now? >>> >>> Presuming that the code is accepted after review and merged, I'm not >>> sure what will happen when we merge that change in from the mainline >>> at a future date. Angus said he "cherry-picked this and squashed the >>> commits with a couple of minor tweaks for compilation warnings in >>> certain configurations." This the merge might not go automatically. >>> >>> Also, I have not done anything to add (optional) immediate sending >>> back into Mongoose. I have not heard of anyone hitting out-of-memory >>> crashes when using SSH with a large burst of output, which is the >>> concern that led me to make the change before when I hit the problem >>> during debugging. Maybe with SPIRAM it is not an issue. SCP is >>> already safe because it does one buffer at a time. >>> >>> -- Steve >>> >>>> On Wed, 21 Feb 2018, Mark Webb-Johnson wrote: >>>> >>>> >>>> My v3.1 test board seems stable, and we are ready for hardware production. I'm ordering the components with relatively long lead times (weeks) now, and the production order will go in as soon as China comes back from holiday (next week). First hardware batch will be available during March. I know lots of people are waiting for this, but I have to balance that against risk (should some hardware issue be found during wider real-world testing). I currently plan to order 120 modules (including 60 USA 3G modems, and 60 EU 3G modems) for the first batch. 100 will go to FastTech (for general ordering), and 20 to me (for special cases). As with OVMS v1, we'll clearly say these are early units for 'technically capable' people, and the firmware still has a way to go. >>>> >>>> On the firmware side, we need to move to a production style release cycle, and I will need to provide the first 'factory' firmware around the second week of March. Accordingly, I'm setting up some clean build environments and OTA release repositories (so I can cleanly build v3.0 and v3.1 firmware and have it available for OTA download). >>>> >>>> I have created a changes.txt log file in the root of the project. I would appreciate it if those with commit access to master could update that file when they merge/commit changes to the project. The top of the file will contain an entry for the 'next' version, so the change text just needs to be added below that. When the version is ready to go, I will update changes.txt with the date and name, commit it, tag it, and then build OTA versions for release. Please only use tags for OTA versions - or just don't tag at all for the moment and let me maintain this. >>>> >>>> The last list of things I have for this build are: >>>> >>>> OTA via HTTP. SD CARD firmware updates seems to work fine today, as does serial flashing. I've still got to make the changes to HTTP firmware updates to use mongoose and support the new ESP IDF v2.1+ firmware arrangement of putting the checksum at the end of the firmware file. >>>> >>>> We need some simple high-level configs for auto-starting things. Stuff like vehicle type, whether the v2 server should auto-run, etc. Make it simpler for people to configure, without having to use scripts. This can be mapped to v2 protocol parameters/features. >>>> >>>> SPI RAM support and stability for v3.1 hardware (as well as compatibility with v3.0 hardware). >>>> >>>> Finalise the partition sizes. I think we can squeeze a bit more (maybe 3x 5MB firmwares, plus 512KB store?). >>>> >>>> End-User Documentation. >>>> >>>> Real-world stability (in cars). >>>> >>>> My concern is to have a relatively stable firmware that is usable for technically capable end-users in their cars, but also to have a way for them to simply update the firmware to keep pace with the fast release cycle we expect (at least in the coming months). >>>> >>>> Anything I've missed? >>>> >>>> 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 -- 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
On Sat, 24 Feb 2018, Michael Balzer wrote:
"make monitor" now also works.
Glad you fixed it.
Btw: according to... https://stackoverflow.com/questions/6908143/should-i-put-shebang-in-python-s... ...the shebang "#!/usr/bin/env python" should not be used.
I don't claim to be a python programmer -- this was an instance of "programming by example" following idf_monitor.py and esptool.py. In the makefile the findcp2102 script is invoked as input to the python binary, so initially I did not include any shebang. But then when I added the mode for running the tool by itself to get the list of CP2102 devices, I figured the shebang would be useful. Interestingly, "#!/usr/bin/env python3" does not work on my Mac laptop, so I must not have python 3 installed. I do remember needing to install py27-serial when beginning the OVMSv3 work in late 2016. What I see is this: auge1> python Python 2.7.13 (default, Apr 25 2017, 10:53:57) [GCC 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.31)] on darwin Type "help", "copyright", "credits" or "license" for more information.
import serial print serial.VERSION 3.0
I'm not sure how this situation compares to yours before the upgrade you've just done. -- Steve
For what it's worth (if anything), I'm on OpenSuSE Tumbleweed. No problem updating the OVMS and esp-idf code. updated ovms as usual, then git pull from esp-idf. From ovms did a make, make flash, make monitor. All worked (for a change!). Got a small surprise asking to confirm the use of the custom partition table (accepted the default) on the first make, but no apparent issue with the results (all config files untouched). Greg Michael Balzer wrote:
Stephen,
today I've learned something about python… ;)
My distribution (openSuSE 42.3) still uses python2 as the base version, and python3 is also installed to enable transition.
I thought I had installed pyserial-3.4 by doing "pip install --uprade pyserial" -- because it told me I had done so:
leela:~ # pip install --upgrade pyserial Collecting pyserial Using cached pyserial-3.4-py2.py3-none-any.whl Installing collected packages: pyserial Uninstalling pyserial-2.7: Successfully uninstalled pyserial-2.7 Successfully installed pyserial-3.4
But it now turned out it only installed the update for the python3 environment, while python2 still used pyserial 2.7. Apparently "pip" is only installed for the python3 environment.
After doing a manual update on the python2 pyserial package, the script now works. So for anyone with a similar setup/issue, do this:
- download the tar.gz from https://pypi.python.org/pypi/pyserial - tar xzf pyserial-3.4.tar.gz - cd pyserial-3.4 - python setup.py install
"make monitor" now also works.
Btw: according to… https://stackoverflow.com/questions/6908143/should-i-put-shebang-in-python-s... …the shebang "#!/usr/bin/env python" should not be used.
Regards, Michael
Am 24.02.2018 um 17:58 schrieb Stephen Casner:
Michael,
I hope you have figured out your python version. Indeed the findcp2102.py code has a dependency on version 3, but since there was a check elsewhere in the esp-idf make process already I figured this was safe.
-- Steve
On Sat, 24 Feb 2018, Michael Balzer wrote:
Something's wrong with my python setup. The documentation says pyserial changed from tuples to objects in version 3, I've got 3.4 and apparently still get tuples.
I remember doing an update on pyserial in order to get miniterm running. The update didn't help but seemed to be successfull. I now think it actually wasn't.
Time for a reinstall...
Am 24.02.2018 um 10:45 schrieb Michael Balzer:
Is there a specific requirement for the findcp2102 tool?
balzer@leela:~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3> make Traceback (most recent call last): File "/home/balzer/esp/esp-idf/tools/findcp2102.py", line 47, in <module> pl.sort(key=lambda x: x.location, reverse=False) File "/home/balzer/esp/esp-idf/tools/findcp2102.py", line 47, in <lambda> pl.sort(key=lambda x: x.location, reverse=False) AttributeError: 'tuple' object has no attribute 'location'
balzer@leela:~/esp/esp-idf> python -m serial.tools.list_ports -v "USB VID:PID=10c4:ea60" Filtered list with regexp: 'USB VID:PID=10c4:ea60' /dev/ttyUSB0 desc: Silicon Labs CP2102 USB to UART Bridge Controller 0001 hwid: USB VID:PID=10c4:ea60 SNR=0001 1 ports found
balzer@leela:~/esp/esp-idf> python --version Python 2.7.12
leela:~ # pip freeze | grep -i serial pyserial==3.4
I've tried running it with python3.4, but that throws syntax errors.
Michael
Am 24.02.2018 um 09:10 schrieb Stephen Casner:
OK, I have merged the latest commits from espressif/esp-idf/master into our fork openvehicles/esp-idf/master and merged the corresponding update to ovms_module to match the changed API for getting per-task heap info.
This means developers need to update both ESP IDF and OVMS v3 source trees (borrowing the lines from Mark's message about mDNS update):
cd ~/esp/esp-idf git pull git submodule update
cd ~/ovms/vehicle/OVMS.V3 git pull make
(changing paths as appropriate)
Also included is a fix for the "module tasks" command to show the stack size correctly again. That breakage was apparently caused by a change in the compiler behavior when espressif recently updated the toolchain for the esp-idf.
-- Steve
On Sat, 24 Feb 2018, Mark Webb-Johnson wrote:
Ok. Got for it.
Regards, Mark
> On 24 Feb 2018, at 8:40 AM, Stephen Casner <casner@acm.org> wrote: > > My PR for heap task tracking has now been merged into espressif/esp-idf/master. > Shall I merge to openvehicles/esp-idf/master and merge the corresponding update > to ovms_module? > > Also, I have pushed a little cleanup commit. I assume that need not be > mentioned in the changes.txt file. > > -- Steve > >> On Tue, 20 Feb 2018, Stephen Casner wrote: >> >> I can wait on these things. Tonight my PR got the "changes approved" >> checkmark. >> >> https://github.com/espressif/esp-idf/pull/1498#pullrequestreview-88994221 >> >> -- Steve >> >> On Wed, 21 Feb 2018, Mark Webb-Johnson wrote: >> >>>> Would you like me to merge the code to openvehicles/esp-idf and >>>> openvehicles/Open-Vehicle-Monitoring-System-3 now? >>> I don't think we are in a hurry for this. What we have now works (since I updated our clone to latest espressif master and brought in their latest SPI RAM fixes). >>> >>> Can we just wait until it is accepted, and then deal with the merge then? >>> >>>> Also, I have not done anything to add (optional) immediate sending >>>> back into Mongoose. >>> That (mongoose) is on my list for moving to SPI RAM. That should reduce the impact of this. >>> >>> Not sure if we still need the immediate sending option. What do you think? If we do, it can be made to our clone of mongoose. >>> >>> Regards, Mark. >>> >>>> On 21 Feb 2018, at 10:52 AM, Stephen Casner <casner@acm.org> wrote: >>>> >>>> Mark, >>>> >>>> As I mentioned in an earlier email, the API for the function call to >>>> gather per-task heap allocation information has changed as part of the >>>> process of getting the feature added to the mainline. That change >>>> currently sits in the "review & merge queue" which is also subject to >>>> delay due to Chinese New Year. >>>> >>>> Would you like me to merge the code to openvehicles/esp-idf and >>>> openvehicles/Open-Vehicle-Monitoring-System-3 now? >>>> >>>> Presuming that the code is accepted after review and merged, I'm not >>>> sure what will happen when we merge that change in from the mainline >>>> at a future date. Angus said he "cherry-picked this and squashed the >>>> commits with a couple of minor tweaks for compilation warnings in >>>> certain configurations." This the merge might not go automatically. >>>> >>>> Also, I have not done anything to add (optional) immediate sending >>>> back into Mongoose. I have not heard of anyone hitting out-of-memory >>>> crashes when using SSH with a large burst of output, which is the >>>> concern that led me to make the change before when I hit the problem >>>> during debugging. Maybe with SPIRAM it is not an issue. SCP is >>>> already safe because it does one buffer at a time. >>>> >>>> -- Steve >>>> >>>>> On Wed, 21 Feb 2018, Mark Webb-Johnson wrote: >>>>> >>>>> >>>>> My v3.1 test board seems stable, and we are ready for hardware production. I'm ordering the components with relatively long lead times (weeks) now, and the production order will go in as soon as China comes back from holiday (next week). First hardware batch will be available during March. I know lots of people are waiting for this, but I have to balance that against risk (should some hardware issue be found during wider real-world testing). I currently plan to order 120 modules (including 60 USA 3G modems, and 60 EU 3G modems) for the first batch. 100 will go to FastTech (for general ordering), and 20 to me (for special cases). As with OVMS v1, we'll clearly say these are early units for 'technically capable' people, and the firmware still has a way to go. >>>>> >>>>> On the firmware side, we need to move to a production style release cycle, and I will need to provide the first 'factory' firmware around the second week of March. Accordingly, I'm setting up some clean build environments and OTA release repositories (so I can cleanly build v3.0 and v3.1 firmware and have it available for OTA download). >>>>> >>>>> I have created a changes.txt log file in the root of the project. I would appreciate it if those with commit access to master could update that file when they merge/commit changes to the project. The top of the file will contain an entry for the 'next' version, so the change text just needs to be added below that. When the version is ready to go, I will update changes.txt with the date and name, commit it, tag it, and then build OTA versions for release. Please only use tags for OTA versions - or just don't tag at all for the moment and let me maintain this. >>>>> >>>>> The last list of things I have for this build are: >>>>> >>>>> OTA via HTTP. SD CARD firmware updates seems to work fine today, as does serial flashing. I've still got to make the changes to HTTP firmware updates to use mongoose and support the new ESP IDF v2.1+ firmware arrangement of putting the checksum at the end of the firmware file. >>>>> >>>>> We need some simple high-level configs for auto-starting things. Stuff like vehicle type, whether the v2 server should auto-run, etc. Make it simpler for people to configure, without having to use scripts. This can be mapped to v2 protocol parameters/features. >>>>> >>>>> SPI RAM support and stability for v3.1 hardware (as well as compatibility with v3.0 hardware). >>>>> >>>>> Finalise the partition sizes. I think we can squeeze a bit more (maybe 3x 5MB firmwares, plus 512KB store?). >>>>> >>>>> End-User Documentation. >>>>> >>>>> Real-world stability (in cars). >>>>> >>>>> My concern is to have a relatively stable firmware that is usable for technically capable end-users in their cars, but also to have a way for them to simply update the firmware to keep pace with the fast release cycle we expect (at least in the coming months). >>>>> >>>>> Anything I've missed? >>>>> >>>>> 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 -- 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
Am 21.02.2018 um 03:05 schrieb Mark Webb-Johnson:
On the firmware side, we need to move to a production style release cycle, and I will need to provide the first ‘factory’ firmware around the second week of March. Accordingly, I’m setting up some clean build environments and OTA release repositories (so I can cleanly build v3.0 and v3.1 firmware and have it available for OTA download).
I have created a changes.txt log file in the root of the project. I would appreciate it if those with commit access to master could update that file when they merge/commit changes to the project. The top of the file will contain an entry for the ‘next’ version, so the change text just needs to be added below that. When the version is ready to go, I will update changes.txt with the date and name, commit it, tag it, and then build OTA versions for release. Please only use tags for OTA versions - or just don’t tag at all for the moment and let me maintain this.
OK. How about using separate branches for release and development. That way we can cherry-pick important fixes early into the release branch if necessary.
The last list of things I have for this build are:
1. OTA via HTTP. SD CARD firmware updates seems to work fine today, as does serial flashing. I’ve still got to make the changes to HTTP firmware updates to use mongoose and support the new ESP IDF v2.1+ firmware arrangement of putting the checksum at the end of the firmware file.
2. We need some simple high-level configs for auto-starting things. Stuff like vehicle type, whether the v2 server should auto-run, etc. Make it simpler for people to configure, without having to use scripts. This can be mapped to v2 protocol parameters/features.
Config for vehicle type is there (added that for the web UI), but I haven't done the auto start on this. With automatic start of the vehicle module, wifi, modem & server connections, I think we need a rescue scheme. I.e. if the boot crashes, the reboot should automatically be done without any auto start -- otherwise the only option to get back to a working module would be to erase the config. I'll have a look at that. Btw, how about activating wifi AP mode as the factory default, i.e. with SSID "OVMS" and password derived from the MAC or ICCID? That way a new user can power the module on and directly connect to the OVMS AP and do the initial configuration with his/her browser. Regards, Michael
1.
2. SPI RAM support and stability for v3.1 hardware (as well as compatibility with v3.0 hardware).
3. Finalise the partition sizes. I think we can squeeze a bit more (maybe 3x 5MB firmwares, plus 512KB store?).
4. End-User Documentation.
5. Real-world stability (in cars).
My concern is to have a relatively stable firmware that is usable for technically capable end-users in their cars, but also to have a way for them to simply update the firmware to keep pace with the fast release cycle we expect (at least in the coming months).
Anything I’ve missed?
Regards, Mark.
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
OK. How about using separate branches for release and development. That way we can cherry-pick important fixes early into the release branch if necessary.
Yes, probably a good idea. I’ll do it just before the first release. Note that we also have the menuconfig CONFIG_OVMS_VERSION_TAG (default: “main”). I plan to use that for OTA to be able to switch to different versions and different release priorities. So, we can have an OTA version X release for beta cars, and OTA version Y for everybody else.
With automatic start of the vehicle module, wifi, modem & server connections, I think we need a rescue scheme. I.e. if the boot crashes, the reboot should automatically be done without any auto start -- otherwise the only option to get back to a working module would be to erase the config. I'll have a look at that.
When looking at the deep sleep stuff, I found there is a way to tag a global variable as ‘rtc’. That should survive a deep sleep (or reboot). For example: https://github.com/espressif/esp-idf/blob/3ede9f011b50999b0560683f9419538c06... <https://github.com/espressif/esp-idf/blob/3ede9f011b50999b0560683f9419538c066dd09e/examples/system/deep_sleep/main/deep_sleep_example_main.c> static RTC_DATA_ATTR struct timeval sleep_enter_time; I did like the feature we had in v2 that recorded the number of resets, as well as the cause of the last reset. Perhaps we can do the same for v3 and store in a metric on boot? Presumably we can set a flag during startup (in rtc ram) and clear it once the startup has been completed. Then when booting if that flag is set, don’t do this auto stuff. That should give us the rescue scheme. I suggest to put this all in one RTC_DATA_ATTR structure in ovms.h (and ovms.cpp), then do the automation either in housekeeping or in a new ovms_auto.{h,cpp} component. Should we create a ‘auto’ config area to store all this? Such as auto/vehicletype, etc...
Btw, how about activating wifi AP mode as the factory default, i.e. with SSID "OVMS" and password derived from the MAC or ICCID? That way a new user can power the module on and directly connect to the OVMS AP and do the initial configuration with his/her browser.
Yes, that makes good sense. Again, it can go in ‘auto’ section, wifiap or something like that. Can default to on, and be explicitly disabled by config later. Regarding the password, not all modules will have ICCID. The MAC address is not externally visible. Maybe just have the access point named OVMS.<last-bit-of-mac> and password OVMS? Then provide a facility in the web UI to be able to change that password? P.S. Your work on the web UI is incredible. Really neat and powerful. Very impressed. Regards, Mark.
On 22 Feb 2018, at 4:21 AM, Michael Balzer <dexter@expeedo.de> wrote:
Am 21.02.2018 um 03:05 schrieb Mark Webb-Johnson:
On the firmware side, we need to move to a production style release cycle, and I will need to provide the first ‘factory’ firmware around the second week of March. Accordingly, I’m setting up some clean build environments and OTA release repositories (so I can cleanly build v3.0 and v3.1 firmware and have it available for OTA download).
I have created a changes.txt log file in the root of the project. I would appreciate it if those with commit access to master could update that file when they merge/commit changes to the project. The top of the file will contain an entry for the ‘next’ version, so the change text just needs to be added below that. When the version is ready to go, I will update changes.txt with the date and name, commit it, tag it, and then build OTA versions for release. Please only use tags for OTA versions - or just don’t tag at all for the moment and let me maintain this.
OK. How about using separate branches for release and development. That way we can cherry-pick important fixes early into the release branch if necessary.
The last list of things I have for this build are:
OTA via HTTP. SD CARD firmware updates seems to work fine today, as does serial flashing. I’ve still got to make the changes to HTTP firmware updates to use mongoose and support the new ESP IDF v2.1+ firmware arrangement of putting the checksum at the end of the firmware file.
We need some simple high-level configs for auto-starting things. Stuff like vehicle type, whether the v2 server should auto-run, etc. Make it simpler for people to configure, without having to use scripts. This can be mapped to v2 protocol parameters/features.
Config for vehicle type is there (added that for the web UI), but I haven't done the auto start on this.
With automatic start of the vehicle module, wifi, modem & server connections, I think we need a rescue scheme. I.e. if the boot crashes, the reboot should automatically be done without any auto start -- otherwise the only option to get back to a working module would be to erase the config. I'll have a look at that.
Btw, how about activating wifi AP mode as the factory default, i.e. with SSID "OVMS" and password derived from the MAC or ICCID? That way a new user can power the module on and directly connect to the OVMS AP and do the initial configuration with his/her browser.
Regards, Michael
SPI RAM support and stability for v3.1 hardware (as well as compatibility with v3.0 hardware).
Finalise the partition sizes. I think we can squeeze a bit more (maybe 3x 5MB firmwares, plus 512KB store?).
End-User Documentation.
Real-world stability (in cars).
My concern is to have a relatively stable firmware that is usable for technically capable end-users in their cars, but also to have a way for them to simply update the firmware to keep pace with the fast release cycle we expect (at least in the coming months).
Anything I’ve missed?
Regards, Mark.
-- 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
Hi Mark, I like the idea of being able to configure the module by the internal website via AP mode WiFi. That's about as close to a universal interface as exists on the planet right now. There probably isn't a need for a custom SSID based on MAC or other serialization; that would only be necessary if configuring multiple modules at the same time in the same place. Use case? But if we have the wifi open (or fixed key) out of the box, it might be a good idea to have a required step of the configuration procedure be to force a passkey change and re-connect on the part of the user. That way, the car can't be controlled until it's configured, and once configured it won't have the default AP passkey. If things get messed up or forgotten, can't the module be reset to factory with some button sequence? I asked that regarding my /store issue, but never heard back. Greg Mark Webb-Johnson wrote:
Regarding the password, not all modules will have ICCID. The MAC address is not externally visible. Maybe just have the access point named OVMS.<last-bit-of-mac> and password OVMS? Then provide a facility in the web UI to be able to change that password?
There probably isn't a need for a custom SSID based on MAC or other serialization; that would only be necessary if configuring multiple modules at the same time in the same place. Use case?
Yep. My thoughts exactly.
it might be a good idea to have a required step of the configuration procedure be to force a passkey change and re-connect on the part of the user.
Yep. If we ask them to specify the AP name, and new password, then that resolves both problems.
If things get messed up or forgotten, can't the module be reset to factory with some button sequence? I asked that regarding my /store issue, but never heard back.
We have two buttons: Hardwired RESET. That resets the chip. IO0 BOOT. If held during BOOT, that goes into firmware download mode. So, only #2 is usable, and that only after boot. I guess we could have a boot delay to allow time for it to be pressed after power up. But, that would require opening up the case to get to the button. Nasty. Plugging it into a PC is probably easier? Regards, Mark.
On 22 Feb 2018, at 12:37 PM, Greg D. <gregd2350@gmail.com> wrote:
Hi Mark,
I like the idea of being able to configure the module by the internal website via AP mode WiFi. That's about as close to a universal interface as exists on the planet right now. There probably isn't a need for a custom SSID based on MAC or other serialization; that would only be necessary if configuring multiple modules at the same time in the same place. Use case?
But if we have the wifi open (or fixed key) out of the box, it might be a good idea to have a required step of the configuration procedure be to force a passkey change and re-connect on the part of the user. That way, the car can't be controlled until it's configured, and once configured it won't have the default AP passkey.
If things get messed up or forgotten, can't the module be reset to factory with some button sequence? I asked that regarding my /store issue, but never heard back.
Greg
Mark Webb-Johnson wrote:
Regarding the password, not all modules will have ICCID. The MAC address is not externally visible. Maybe just have the access point named OVMS.<last-bit-of-mac> and password OVMS? Then provide a facility in the web UI to be able to change that password?
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I guess the AUTO stuff Michael has been talking about could handle this. If BOOT (IO0) button held down for X seconds that auto-launch a wifi AP. If held down for Y seconds, then factory reset? Just a hassle to do, with user having to open the case. Certainly too late to change case design for these first few hundred units. Regards, Mark. P.S. I mean “PC” in the wider sense of the word. Not too hard to hook-up on linux, mac, or windows.
On 22 Feb 2018, at 1:22 PM, Greg D. <gregd2350@gmail.com> wrote:
Hi Mark,
See below...
Greg
Mark Webb-Johnson wrote:
If things get messed up or forgotten, can't the module be reset to factory with some button sequence? I asked that regarding my /store issue, but never heard back.
We have two buttons:
Hardwired RESET. That resets the chip. IO0 BOOT. If held during BOOT, that goes into firmware download mode.
So, only #2 is usable, and that only after boot. I guess we could have a boot delay to allow time for it to be pressed after power up. Yes, something like that. I've worked on products where holding button #2 after releasing #1 would first take the product into a reset-to-defaults mode for about 10 seconds, then if you kept holding it after that, would take you to the downloader.
But, that would require opening up the case to get to the button. Nasty. Plugging it into a PC is probably easier? Hooking to a PC wouldn't necessarily be easier, but certainly safer. I take it that the buttons on the 3.1 hardware aren't anywhere that can be accessed through a proverbial paper clip-sized hole, nor in such a way that a metal paper clip wouldn't be in danger of hitting something live. Opening my box, I see the 3.0 hardware is not set up that way. The switches would need to be moved to the back side of the board for that, and the holes put in the case. Are we too late?
I guess we can assume that our customers are at least somewhat technology-literate, and in the event that they lose their AP pass key, a USB serial console might be a reasonable way to reset things. But if the only "PCs" they own are a smart phone and tablet, or in the event that the module is password protected too, use of the buttons would still be required. Or, they can cash in their "phone a friend" token. :) PCs aren't totally obsolete, yet.
Greg
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Wintel not assumed. I think of my eldest, a doctor, who uses a phone and a tablet. She has (owns) a Laptop computer, but hasn't booted it in years. There are a lot of "young'uns" in a similar situation. As long as there's a safe (brick-proof) way back to sanity using only common tools, documentation, and the odd toothpick, we should be good. Greg Mark Webb-Johnson wrote:
P.S. I mean “PC” in the wider sense of the word. Not too hard to hook-up on linux, mac, or windows.
The other option is SD CARD. Firmware update can work that way. Put an ovms3.bin in the root of an SD card, plug it in, and it will be auto-flashed to update firmware. We could have special files on SD CARD doing certain things. Like safe boot. Factory reset. Wifi AP. etc. Can we write an SD CARD from an iPad? :-) Regards, Mark.
On 22 Feb 2018, at 2:13 PM, Greg D. <gregd2350@gmail.com> wrote:
Wintel not assumed. I think of my eldest, a doctor, who uses a phone and a tablet. She has (owns) a Laptop computer, but hasn't booted it in years. There are a lot of "young'uns" in a similar situation.
As long as there's a safe (brick-proof) way back to sanity using only common tools, documentation, and the odd toothpick, we should be good.
Greg
Mark Webb-Johnson wrote:
P.S. I mean “PC” in the wider sense of the word. Not too hard to hook-up on linux, mac, or windows.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Ha, good thought! Put a text file in the root directory named "factoryreset.txt" containing "OVMSv3" as a key, stick it in, and power up. Done. Brilliant. It probably should remove said file once the config is cleared, as a fail-safe. Don't want it to act as a poison pill. Only "gotcha" is that finding things that can write to a micro SD card is becoming harder. No to the iPhone. Also my latest Android, though it does have an OTG adapter so I can get there with a USB reader. The ecosystem is trying to force storage to a (paid, data mine-able) cloud, I think, using space and cost savings as a ruse. Greg Mark Webb-Johnson wrote:
The other option is SD CARD.
Firmware update can work that way. Put an ovms3.bin in the root of an SD card, plug it in, and it will be auto-flashed to update firmware.
We could have special files on SD CARD doing certain things. Like safe boot. Factory reset. Wifi AP. etc.
Can we write an SD CARD from an iPad? :-)
Regards, Mark.
On 22 Feb 2018, at 2:13 PM, Greg D. <gregd2350@gmail.com> wrote:
Wintel not assumed. I think of my eldest, a doctor, who uses a phone and a tablet. She has (owns) a Laptop computer, but hasn't booted it in years. There are a lot of "young'uns" in a similar situation.
As long as there's a safe (brick-proof) way back to sanity using only common tools, documentation, and the odd toothpick, we should be good.
Greg
Mark Webb-Johnson wrote:
P.S. I mean “PC” in the wider sense of the word. Not too hard to hook-up on linux, mac, or windows.
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
Reality has proven we need some simple way to do a factory reset, we've got users that don't know how to use a serial USB terminal. I've implemented the button and SD card methods discussed earlier. To do a factory reset you can now alternatively to using "module factory reset"… * a) Insert an SD card that has a file "factoryreset.txt" in the root directory. The file will be erased, as will be your configuration. * b) Open the module, remove any SD card, power the module up, wait for 2-3 seconds until boot has finished, then push and hold SW2 for 10 seconds. The SD card needs to be remove for method b because SW2 grounds SD_DATA0 as well. Besides the slight chance to trigger 10 false readings from a running transmission, I also found the SD driver to be unforgiving about pushing SW2 during a transfer. It will eventually lock up the module completely needing a hard reboot. So it's better to require SD removal for this method. Regards, Michael Am 22.02.2018 um 07:30 schrieb Greg D.:
Ha, good thought! Put a text file in the root directory named "factoryreset.txt" containing "OVMSv3" as a key, stick it in, and power up. Done. Brilliant.
It probably should remove said file once the config is cleared, as a fail-safe. Don't want it to act as a poison pill.
Only "gotcha" is that finding things that can write to a micro SD card is becoming harder. No to the iPhone. Also my latest Android, though it does have an OTG adapter so I can get there with a USB reader. The ecosystem is trying to force storage to a (paid, data mine-able) cloud, I think, using space and cost savings as a ruse.
Greg
Mark Webb-Johnson wrote:
The other option is SD CARD.
Firmware update can work that way. Put an ovms3.bin in the root of an SD card, plug it in, and it will be auto-flashed to update firmware.
We could have special files on SD CARD doing certain things. Like safe boot. Factory reset. Wifi AP. etc.
Can we write an SD CARD from an iPad? :-)
Regards, Mark.
Am 22.02.2018 um 06:22 schrieb Greg D.:
We have two buttons:
1. Hardwired RESET. That resets the chip. 2. IO0 BOOT. If held during BOOT, that goes into firmware download mode.
So, only #2 is usable, and that only after boot. I guess we could have a boot delay to allow time for it to be pressed after power up.
Yes, something like that. I've worked on products where holding button #2 after releasing #1 would first take the product into a reset-to-defaults mode for about 10 seconds, then if you kept holding it after that, would take you to the downloader.
But, that would require opening up the case to get to the button. Nasty. Plugging it into a PC is probably easier?
Hooking to a PC wouldn't necessarily be easier, but certainly safer. I take it that the buttons on the 3.1 hardware aren't anywhere that can be accessed through a proverbial paper clip-sized hole, nor in such a way that a metal paper clip wouldn't be in danger of hitting something live. Opening my box, I see the 3.0 hardware is not set up that way. The switches would need to be moved to the back side of the board for that, and the holes put in the case. Are we too late?
I guess we can assume that our customers are at least somewhat technology-literate, and in the event that they lose their AP pass key, a USB serial console might be a reasonable way to reset things. But if the only "PCs" they own are a smart phone and tablet, or in the event that the module is password protected too, use of the buttons would still be required. Or, they can cash in their "phone a friend" token. :) PCs aren't totally obsolete, yet.
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
As those users also will not be able to enter "config" commands, I don't see another option than to enable wifi AP mode with a default password. We can read the "factoryreset.txt" file contents and use the first line as the module password, but that doesn't catch the factory reset by S2. I have pushed the change. After a factory reset the module now starts with wifi mode AP, network "OVMS" and password "OVMSinit". Regards, Michael Am 15.04.2018 um 17:24 schrieb Michael Balzer:
Reality has proven we need some simple way to do a factory reset, we've got users that don't know how to use a serial USB terminal.
I've implemented the button and SD card methods discussed earlier.
To do a factory reset you can now alternatively to using "module factory reset"…
* a) Insert an SD card that has a file "factoryreset.txt" in the root directory. The file will be erased, as will be your configuration. * b) Open the module, remove any SD card, power the module up, wait for 2-3 seconds until boot has finished, then push and hold SW2 for 10 seconds.
The SD card needs to be remove for method b because SW2 grounds SD_DATA0 as well. Besides the slight chance to trigger 10 false readings from a running transmission, I also found the SD driver to be unforgiving about pushing SW2 during a transfer. It will eventually lock up the module completely needing a hard reboot. So it's better to require SD removal for this method.
Regards, Michael
Am 22.02.2018 um 07:30 schrieb Greg D.:
Ha, good thought! Put a text file in the root directory named "factoryreset.txt" containing "OVMSv3" as a key, stick it in, and power up. Done. Brilliant.
It probably should remove said file once the config is cleared, as a fail-safe. Don't want it to act as a poison pill.
Only "gotcha" is that finding things that can write to a micro SD card is becoming harder. No to the iPhone. Also my latest Android, though it does have an OTG adapter so I can get there with a USB reader. The ecosystem is trying to force storage to a (paid, data mine-able) cloud, I think, using space and cost savings as a ruse.
Greg
Mark Webb-Johnson wrote:
The other option is SD CARD.
Firmware update can work that way. Put an ovms3.bin in the root of an SD card, plug it in, and it will be auto-flashed to update firmware.
We could have special files on SD CARD doing certain things. Like safe boot. Factory reset. Wifi AP. etc.
Can we write an SD CARD from an iPad? :-)
Regards, Mark.
Am 22.02.2018 um 06:22 schrieb Greg D.:
We have two buttons:
1. Hardwired RESET. That resets the chip. 2. IO0 BOOT. If held during BOOT, that goes into firmware download mode.
So, only #2 is usable, and that only after boot. I guess we could have a boot delay to allow time for it to be pressed after power up.
Yes, something like that. I've worked on products where holding button #2 after releasing #1 would first take the product into a reset-to-defaults mode for about 10 seconds, then if you kept holding it after that, would take you to the downloader.
But, that would require opening up the case to get to the button. Nasty. Plugging it into a PC is probably easier?
Hooking to a PC wouldn't necessarily be easier, but certainly safer. I take it that the buttons on the 3.1 hardware aren't anywhere that can be accessed through a proverbial paper clip-sized hole, nor in such a way that a metal paper clip wouldn't be in danger of hitting something live. Opening my box, I see the 3.0 hardware is not set up that way. The switches would need to be moved to the back side of the board for that, and the holes put in the case. Are we too late?
I guess we can assume that our customers are at least somewhat technology-literate, and in the event that they lose their AP pass key, a USB serial console might be a reasonable way to reset things. But if the only "PCs" they own are a smart phone and tablet, or in the event that the module is password protected too, use of the buttons would still be required. Or, they can cash in their "phone a friend" token. :) PCs aren't totally obsolete, yet.
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Note that a Factory reset may not turn on WiFi. See my post on OVMS——there appears to be an issue with setting of the password(s) that disables WiFi. Sent from my tablet
On Apr 15, 2018, at 8:24 AM, Michael Balzer <dexter@expeedo.de> wrote:
Reality has proven we need some simple way to do a factory reset, we've got users that don't know how to use a serial USB terminal.
I've implemented the button and SD card methods discussed earlier.
To do a factory reset you can now alternatively to using "module factory reset"… a) Insert an SD card that has a file "factoryreset.txt" in the root directory. The file will be erased, as will be your configuration. b) Open the module, remove any SD card, power the module up, wait for 2-3 seconds until boot has finished, then push and hold SW2 for 10 seconds. The SD card needs to be remove for method b because SW2 grounds SD_DATA0 as well. Besides the slight chance to trigger 10 false readings from a running transmission, I also found the SD driver to be unforgiving about pushing SW2 during a transfer. It will eventually lock up the module completely needing a hard reboot. So it's better to require SD removal for this method.
Regards, Michael
Am 22.02.2018 um 07:30 schrieb Greg D.: Ha, good thought! Put a text file in the root directory named "factoryreset.txt" containing "OVMSv3" as a key, stick it in, and power up. Done. Brilliant.
It probably should remove said file once the config is cleared, as a fail-safe. Don't want it to act as a poison pill.
Only "gotcha" is that finding things that can write to a micro SD card is becoming harder. No to the iPhone. Also my latest Android, though it does have an OTG adapter so I can get there with a USB reader. The ecosystem is trying to force storage to a (paid, data mine-able) cloud, I think, using space and cost savings as a ruse.
Greg
Mark Webb-Johnson wrote:
The other option is SD CARD.
Firmware update can work that way. Put an ovms3.bin in the root of an SD card, plug it in, and it will be auto-flashed to update firmware.
We could have special files on SD CARD doing certain things. Like safe boot. Factory reset. Wifi AP. etc.
Can we write an SD CARD from an iPad? :-)
Regards, Mark.
Am 22.02.2018 um 06:22 schrieb Greg D.: We have two buttons:
Hardwired RESET. That resets the chip. IO0 BOOT. If held during BOOT, that goes into firmware download mode. So, only #2 is usable, and that only after boot. I guess we could have a boot delay to allow time for it to be pressed after power up.
Yes, something like that. I've worked on products where holding button #2 after releasing #1 would first take the product into a reset-to-defaults mode for about 10 seconds, then if you kept holding it after that, would take you to the downloader.
But, that would require opening up the case to get to the button. Nasty. Plugging it into a PC is probably easier?
Hooking to a PC wouldn't necessarily be easier, but certainly safer. I take it that the buttons on the 3.1 hardware aren't anywhere that can be accessed through a proverbial paper clip-sized hole, nor in such a way that a metal paper clip wouldn't be in danger of hitting something live. Opening my box, I see the 3.0 hardware is not set up that way. The switches would need to be moved to the back side of the board for that, and the holes put in the case. Are we too late?
I guess we can assume that our customers are at least somewhat technology-literate, and in the event that they lose their AP pass key, a USB serial console might be a reasonable way to reset things. But if the only "PCs" they own are a smart phone and tablet, or in the event that the module is password protected too, use of the buttons would still be required. Or, they can cash in their "phone a friend" token. :) PCs aren't totally obsolete, yet.
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Charles, see my previous message, the new version is already available on my server. Regards, Michael Am 15.04.2018 um 20:20 schrieb Charles Cangialose:
Note that a Factory reset may not turn on WiFi. See my post on OVMS——there appears to be an issue with setting of the password(s) that disables WiFi.
Sent from my tablet
On Apr 15, 2018, at 8:24 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Reality has proven we need some simple way to do a factory reset, we've got users that don't know how to use a serial USB terminal.
I've implemented the button and SD card methods discussed earlier.
To do a factory reset you can now alternatively to using "module factory reset"…
* a) Insert an SD card that has a file "factoryreset.txt" in the root directory. The file will be erased, as will be your configuration. * b) Open the module, remove any SD card, power the module up, wait for 2-3 seconds until boot has finished, then push and hold SW2 for 10 seconds.
The SD card needs to be remove for method b because SW2 grounds SD_DATA0 as well. Besides the slight chance to trigger 10 false readings from a running transmission, I also found the SD driver to be unforgiving about pushing SW2 during a transfer. It will eventually lock up the module completely needing a hard reboot. So it's better to require SD removal for this method.
Regards, Michael
Am 22.02.2018 um 07:30 schrieb Greg D.:
Ha, good thought! Put a text file in the root directory named "factoryreset.txt" containing "OVMSv3" as a key, stick it in, and power up. Done. Brilliant.
It probably should remove said file once the config is cleared, as a fail-safe. Don't want it to act as a poison pill.
Only "gotcha" is that finding things that can write to a micro SD card is becoming harder. No to the iPhone. Also my latest Android, though it does have an OTG adapter so I can get there with a USB reader. The ecosystem is trying to force storage to a (paid, data mine-able) cloud, I think, using space and cost savings as a ruse.
Greg
Mark Webb-Johnson wrote:
The other option is SD CARD.
Firmware update can work that way. Put an ovms3.bin in the root of an SD card, plug it in, and it will be auto-flashed to update firmware.
We could have special files on SD CARD doing certain things. Like safe boot. Factory reset. Wifi AP. etc.
Can we write an SD CARD from an iPad? :-)
Regards, Mark.
Am 22.02.2018 um 06:22 schrieb Greg D.:
We have two buttons:
1. Hardwired RESET. That resets the chip. 2. IO0 BOOT. If held during BOOT, that goes into firmware download mode.
So, only #2 is usable, and that only after boot. I guess we could have a boot delay to allow time for it to be pressed after power up.
Yes, something like that. I've worked on products where holding button #2 after releasing #1 would first take the product into a reset-to-defaults mode for about 10 seconds, then if you kept holding it after that, would take you to the downloader.
But, that would require opening up the case to get to the button. Nasty. Plugging it into a PC is probably easier?
Hooking to a PC wouldn't necessarily be easier, but certainly safer. I take it that the buttons on the 3.1 hardware aren't anywhere that can be accessed through a proverbial paper clip-sized hole, nor in such a way that a metal paper clip wouldn't be in danger of hitting something live. Opening my box, I see the 3.0 hardware is not set up that way. The switches would need to be moved to the back side of the board for that, and the holes put in the case. Are we too late?
I guess we can assume that our customers are at least somewhat technology-literate, and in the event that they lose their AP pass key, a USB serial console might be a reasonable way to reset things. But if the only "PCs" they own are a smart phone and tablet, or in the event that the module is password protected too, use of the buttons would still be required. Or, they can cash in their "phone a friend" token. :) PCs aren't totally obsolete, yet.
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Michael, Nice work. I like both options. One suggestion: At the moment, you can do a ‘sd unmount’ and then hold the BOOT button to factory reset. It can even be mounted during this reset process. OVMS# sd unmount Unmounted SD CARD W (1321564) ovms-module: SW2 pushed, factory reset in 9 seconds W (1322564) ovms-module: SW2 pushed, factory reset in 8 seconds OVMS# sd mount Error: SD CARD could not be mounted E (1323204) sdmmc_cmd: sdmmc_card_init: send_scr (1) returned 0x109 For safety, is it worth checking isinserted() as well as ismounted() and only allow this to factory reset if the SD is not actually inserted (as well as not mounted)? We’ve had so many troubles with SD CARD support in ESP IDF, I am terrified of going anywhere near it. Regards, Mark.
On 15 Apr 2018, at 11:24 PM, Michael Balzer <dexter@expeedo.de> wrote:
Reality has proven we need some simple way to do a factory reset, we've got users that don't know how to use a serial USB terminal.
I've implemented the button and SD card methods discussed earlier.
To do a factory reset you can now alternatively to using "module factory reset"… a) Insert an SD card that has a file "factoryreset.txt" in the root directory. The file will be erased, as will be your configuration. b) Open the module, remove any SD card, power the module up, wait for 2-3 seconds until boot has finished, then push and hold SW2 for 10 seconds. The SD card needs to be remove for method b because SW2 grounds SD_DATA0 as well. Besides the slight chance to trigger 10 false readings from a running transmission, I also found the SD driver to be unforgiving about pushing SW2 during a transfer. It will eventually lock up the module completely needing a hard reboot. So it's better to require SD removal for this method.
Regards, Michael
Am 22.02.2018 um 07:30 schrieb Greg D.:
Ha, good thought! Put a text file in the root directory named "factoryreset.txt" containing "OVMSv3" as a key, stick it in, and power up. Done. Brilliant.
It probably should remove said file once the config is cleared, as a fail-safe. Don't want it to act as a poison pill.
Only "gotcha" is that finding things that can write to a micro SD card is becoming harder. No to the iPhone. Also my latest Android, though it does have an OTG adapter so I can get there with a USB reader. The ecosystem is trying to force storage to a (paid, data mine-able) cloud, I think, using space and cost savings as a ruse.
Greg
Mark Webb-Johnson wrote:
The other option is SD CARD.
Firmware update can work that way. Put an ovms3.bin in the root of an SD card, plug it in, and it will be auto-flashed to update firmware.
We could have special files on SD CARD doing certain things. Like safe boot. Factory reset. Wifi AP. etc.
Can we write an SD CARD from an iPad? :-)
Regards, Mark.
Am 22.02.2018 um 06:22 schrieb Greg D.:
We have two buttons:
Hardwired RESET. That resets the chip. IO0 BOOT. If held during BOOT, that goes into firmware download mode. So, only #2 is usable, and that only after boot. I guess we could have a boot delay to allow time for it to be pressed after power up.
Yes, something like that. I've worked on products where holding button #2 after releasing #1 would first take the product into a reset-to-defaults mode for about 10 seconds, then if you kept holding it after that, would take you to the downloader.
But, that would require opening up the case to get to the button. Nasty. Plugging it into a PC is probably easier?
Hooking to a PC wouldn't necessarily be easier, but certainly safer. I take it that the buttons on the 3.1 hardware aren't anywhere that can be accessed through a proverbial paper clip-sized hole, nor in such a way that a metal paper clip wouldn't be in danger of hitting something live. Opening my box, I see the 3.0 hardware is not set up that way. The switches would need to be moved to the back side of the board for that, and the holes put in the case. Are we too late?
I guess we can assume that our customers are at least somewhat technology-literate, and in the event that they lose their AP pass key, a USB serial console might be a reasonable way to reset things. But if the only "PCs" they own are a smart phone and tablet, or in the event that the module is password protected too, use of the buttons would still be required. Or, they can cash in their "phone a friend" token. :) PCs aren't totally obsolete, yet.
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Am 16.04.2018 um 03:05 schrieb Mark Webb-Johnson:
Michael,
Nice work. I like both options.
Thanks. Not much work, hopefully helps.
One suggestion:
At the moment, you can do a ‘sd unmount’ and then hold the BOOT button to factory reset. It can even be mounted during this reset process.
OVMS# sd unmount Unmounted SD CARD W (1321564) ovms-module: SW2 pushed, factory reset in 9 seconds W (1322564) ovms-module: SW2 pushed, factory reset in 8 seconds
OVMS# sd mount Error: SD CARD could not be mounted E (1323204) sdmmc_cmd: sdmmc_card_init: send_scr (1) returned 0x109
For safety, is it worth checking isinserted() as well as ismounted() and only allow this to factory reset if the SD is not actually inserted (as well as not mounted)? We’ve had so many troubles with SD CARD support in ESP IDF, I am terrified of going anywhere near it.
I have only thought about the SW2 reading being influenced by SD data yet, not vice versa. I don't think there would be any data transmission if the SD is only inserted, but it doesn't hurt changing the check. For the other direction, I'll add a check of the SW2 state to the mount methods, so no mount is attempted while the button is pressed. I think that should be possible, as we already take care of the insertion detection ourselves. We should add a general warning to the guide though, that pushing the button with an SD card inserted should ultimately be avoided. I guess if you hit the right moment on a write, you can trash the SD filesystem. Regards, Michael
Regards, Mark.
On 15 Apr 2018, at 11:24 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Reality has proven we need some simple way to do a factory reset, we've got users that don't know how to use a serial USB terminal.
I've implemented the button and SD card methods discussed earlier.
To do a factory reset you can now alternatively to using "module factory reset"…
* a) Insert an SD card that has a file "factoryreset.txt" in the root directory. The file will be erased, as will be your configuration. * b) Open the module, remove any SD card, power the module up, wait for 2-3 seconds until boot has finished, then push and hold SW2 for 10 seconds.
The SD card needs to be remove for method b because SW2 grounds SD_DATA0 as well. Besides the slight chance to trigger 10 false readings from a running transmission, I also found the SD driver to be unforgiving about pushing SW2 during a transfer. It will eventually lock up the module completely needing a hard reboot. So it's better to require SD removal for this method.
Regards, Michael
Am 22.02.2018 um 07:30 schrieb Greg D.:
Ha, good thought! Put a text file in the root directory named "factoryreset.txt" containing "OVMSv3" as a key, stick it in, and power up. Done. Brilliant.
It probably should remove said file once the config is cleared, as a fail-safe. Don't want it to act as a poison pill.
Only "gotcha" is that finding things that can write to a micro SD card is becoming harder. No to the iPhone. Also my latest Android, though it does have an OTG adapter so I can get there with a USB reader. The ecosystem is trying to force storage to a (paid, data mine-able) cloud, I think, using space and cost savings as a ruse.
Greg
Mark Webb-Johnson wrote:
The other option is SD CARD.
Firmware update can work that way. Put an ovms3.bin in the root of an SD card, plug it in, and it will be auto-flashed to update firmware.
We could have special files on SD CARD doing certain things. Like safe boot. Factory reset. Wifi AP. etc.
Can we write an SD CARD from an iPad? :-)
Regards, Mark.
Am 22.02.2018 um 06:22 schrieb Greg D.:
We have two buttons:
1. Hardwired RESET. That resets the chip. 2. IO0 BOOT. If held during BOOT, that goes into firmware download mode.
So, only #2 is usable, and that only after boot. I guess we could have a boot delay to allow time for it to be pressed after power up.
Yes, something like that. I've worked on products where holding button #2 after releasing #1 would first take the product into a reset-to-defaults mode for about 10 seconds, then if you kept holding it after that, would take you to the downloader.
But, that would require opening up the case to get to the button. Nasty. Plugging it into a PC is probably easier?
Hooking to a PC wouldn't necessarily be easier, but certainly safer. I take it that the buttons on the 3.1 hardware aren't anywhere that can be accessed through a proverbial paper clip-sized hole, nor in such a way that a metal paper clip wouldn't be in danger of hitting something live. Opening my box, I see the 3.0 hardware is not set up that way. The switches would need to be moved to the back side of the board for that, and the holes put in the case. Are we too late?
I guess we can assume that our customers are at least somewhat technology-literate, and in the event that they lose their AP pass key, a USB serial console might be a reasonable way to reset things. But if the only "PCs" they own are a smart phone and tablet, or in the event that the module is password protected too, use of the buttons would still be required. Or, they can cash in their "phone a friend" token. :) PCs aren't totally obsolete, yet.
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Greg, Mark, I'm a bit concerned about an initially open Wifi access. I know we're not targeting a mass market, but security is always important, especially for a system that can potentially control a car. We need to be -and stay- aware this may introduce a way to hack & hijack the system. You would for example scan for new OVMS wifi networks, do an automatic passkey change to get access, then get the module to install a trojan firmware that mimicks the original behaviour (root kit style) and voila, you've got another bitcoin miner. A normal user will never recognize something's fishy. With our current OTA function that's an unlikely attack vector, you would need to either control the GSM cell / DNS to redirect the download to your trojan site or have hacked the openvehicles.com server to deliver your trojan firmware. But things will evolve. Some users may also not care about the Wifi access (i.e. using just Bluetooth / USB / GSM) and then not be aware it's actually active & open. Is it too expensive to print the Wifi MAC or serial no. onto some label or document for the user? If so we should at least make this very clear in the user documentation. Btw, the same password could be used as the default module password, or we could use the module password for both purposes. Regards, Michael Am 22.02.2018 um 05:52 schrieb Mark Webb-Johnson:
There probably isn't a need for a custom SSID based on MAC or other serialization; that would only be necessary if configuring multiple modules at the same time in the same place. Use case?
Yep. My thoughts exactly.
it might be a good idea to have a required step of the configuration procedure be to force a passkey change and re-connect on the part of the user.
Yep. If we ask them to specify the AP name, and new password, then that resolves both problems.
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
I’m not sure that Wifi MAC helps. That is broadcast as part of the WiFi station announcement, so using it as the password is really not any more secure than a fixed OVMS password. Printing the wifi MAC also would be troublesome, because it would have to be entered into some printing program, and labels individually printed. Messy. Hand-written would not be good. A better approach would be to come at it from the other way. Have the serial numbers / password stickers pre-printed in a large batch. Then, have the factory enter them into the number into the module during initial flashing / QC tests. There is BLK3 of eFuses, but I find those scary. Supposedly it is not used (other than for a custom MAC address), and there are 192/256 bits available. That would be a one-time flash. We could store the serial number as a locally administered MAC address there. It could also go into the flash as a configured parameter. That would be read/write (allowing someone to change the serial number). BLK3 is probably the correct way of doing things, but very scary. That is a one time write (it literally sends too much current down a little wire in the chip - burning it out), and not so easy to debug the code ;-) Regards, Mark.
On 24 Feb 2018, at 5:21 PM, Michael Balzer <dexter@expeedo.de> wrote:
Greg, Mark,
I'm a bit concerned about an initially open Wifi access.
I know we're not targeting a mass market, but security is always important, especially for a system that can potentially control a car.
We need to be -and stay- aware this may introduce a way to hack & hijack the system. You would for example scan for new OVMS wifi networks, do an automatic passkey change to get access, then get the module to install a trojan firmware that mimicks the original behaviour (root kit style) and voila, you've got another bitcoin miner. A normal user will never recognize something's fishy.
With our current OTA function that's an unlikely attack vector, you would need to either control the GSM cell / DNS to redirect the download to your trojan site or have hacked the openvehicles.com server to deliver your trojan firmware. But things will evolve.
Some users may also not care about the Wifi access (i.e. using just Bluetooth / USB / GSM) and then not be aware it's actually active & open.
Is it too expensive to print the Wifi MAC or serial no. onto some label or document for the user?
If so we should at least make this very clear in the user documentation.
Btw, the same password could be used as the default module password, or we could use the module password for both purposes.
Regards, Michael
Am 22.02.2018 um 05:52 schrieb Mark Webb-Johnson:
There probably isn't a need for a custom SSID based on MAC or other serialization; that would only be necessary if configuring multiple modules at the same time in the same place. Use case?
Yep. My thoughts exactly.
it might be a good idea to have a required step of the configuration procedure be to force a passkey change and re-connect on the part of the user.
Yep. If we ask them to specify the AP name, and new password, then that resolves both problems.
-- 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
Agree, WiFi's MAC is not useful as a passphrase or password, but I don't think that we need to go to blowing fuses to solve this. Michael, you are absolutely right that we shouldn't leave an open wifi hotspot sitting there; it's an invitation for abuse. But if we have a static passphrase pre-set, and there is nothing one can do with the module in that state - plugged in but not configured - I think that the window for that abuse is going to be vanishingly small. A new customer will get the module and plug it in to either their car or (perhaps better) a standalone USB power source, and then configure it. It won't be left powered but unconfigured for very long. A new wifi AP passphrase can be set during that configuration process (encouraged or enforced), and the issue closed. Especially these days, the most universally accepted means to configure something is with a web server. What you have done with the OVMS web server is very well designed and executed, and I don't see any significant issues with using that approach as the primary means for configuring and managing the module. I spent a few minutes playing with it just now, and I think there are a couple of extensions that would complete the package. The biggest disconnect I see between the webserver and CLI management approaches is the role of files. They are central to the CLI, with little files sprinkled everywhere about the module. For the config items, that's well handled by both methods, but for events, that's a problem. Perhaps this is coming, but I currently don't see where the file tree is visible, nor a facility for creating and editing them. Are these planned, or is there a different means for managing on-board files? Finally, a use-case question. Do we expect folks to be using the wifi client along with the modem, for example, using the wifi connection while at home or work to reduce cellular data fees, with the module flipping over to cellular when on the road? I guess there are two reasons for asking... First to understand what the connectivity and management scenarios are, and second, the known difficulty in flipping between the two connection stacks. Since wifi can be either a client or an AP, not both, anyone using wifi for management can't use it as a client, since there is no easy way to move it back to being an AP. Ok, I suppose an SMS command could turn on AP mode... Is that the intent? As for flipping between cellular and wifi for connectivity to the Internet-based server, the two currently are stepping on each other. If I have both enabled in my startup event script, wifi connects first and I can see the status of the car within a second or two of booting. Then the modem connects, gets an IP address, and things get messy. The v2 server thinks it connected, but it's not (or at least, no data gets through). Disconnecting from wifi (wifi mode off) doesn't fix it, nor does turning off the modem. I have to drop both connections and then bring just one of them up. I guess if this is inherently irreparable, the answer to my question about the role of wifi is easy - it's there for local management only, or in the rare case of client connectivity if in an area devoid of cell service but with access to a home or work network. If we do intend to fix it (my hope), then one has options for connectivity and management. Perhaps this needs to be one of the introductory chapters in the user guide... Greg Mark Webb-Johnson wrote:
I’m not sure that Wifi MAC helps. That is broadcast as part of the WiFi station announcement, so using it as the password is really not any more secure than a fixed OVMS password.
Printing the wifi MAC also would be troublesome, because it would have to be entered into some printing program, and labels individually printed. Messy. Hand-written would not be good.
A better approach would be to come at it from the other way. Have the serial numbers / password stickers pre-printed in a large batch. Then, have the factory enter them into the number into the module during initial flashing / QC tests.
There is BLK3 of eFuses, but I find those scary. Supposedly it is not used (other than for a custom MAC address), and there are 192/256 bits available. That would be a one-time flash. We could store the serial number as a locally administered MAC address there.
It could also go into the flash as a configured parameter. That would be read/write (allowing someone to change the serial number).
BLK3 is probably the correct way of doing things, but very scary. That is a one time write (it literally sends too much current down a little wire in the chip - burning it out), and not so easy to debug the code ;-)
Regards, Mark.
On 24 Feb 2018, at 5:21 PM, Michael Balzer <dexter@expeedo.de> wrote:
Greg, Mark,
I'm a bit concerned about an initially open Wifi access.
I know we're not targeting a mass market, but security is always important, especially for a system that can potentially control a car.
We need to be -and stay- aware this may introduce a way to hack & hijack the system. You would for example scan for new OVMS wifi networks, do an automatic passkey change to get access, then get the module to install a trojan firmware that mimicks the original behaviour (root kit style) and voila, you've got another bitcoin miner. A normal user will never recognize something's fishy.
With our current OTA function that's an unlikely attack vector, you would need to either control the GSM cell / DNS to redirect the download to your trojan site or have hacked the openvehicles.com server to deliver your trojan firmware. But things will evolve.
Some users may also not care about the Wifi access (i.e. using just Bluetooth / USB / GSM) and then not be aware it's actually active & open.
Is it too expensive to print the Wifi MAC or serial no. onto some label or document for the user?
If so we should at least make this very clear in the user documentation.
Btw, the same password could be used as the default module password, or we could use the module password for both purposes.
Regards, Michael
Am 22.02.2018 um 05:52 schrieb Mark Webb-Johnson:
There probably isn't a need for a custom SSID based on MAC or other serialization; that would only be necessary if configuring multiple modules at the same time in the same place. Use case? Yep. My thoughts exactly.
it might be a good idea to have a required step of the configuration procedure be to force a passkey change and re-connect on the part of the user. Yep. If we ask them to specify the AP name, and new password, then that resolves both problems.
-- 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
In order for a module that has been configured to become useful automatically after power cycles it will be necessary for the start-up script(s) to execute commands that require being enabled. If that requires putting an enable command with clear-text password into the startup script, that's not good. -- Steve
Am 25.02.2018 um 01:12 schrieb Stephen Casner:
In order for a module that has been configured to become useful automatically after power cycles it will be necessary for the start-up script(s) to execute commands that require being enabled. If that requires putting an enable command with clear-text password into the startup script, that's not good.
-- Steve
Good point. How about allowing write access to event scripts on "/store" only in enabled mode and then generally run those scripts in enabled mode? Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Michael Balzer wrote:
Am 25.02.2018 um 01:12 schrieb Stephen Casner:
In order for a module that has been configured to become useful automatically after power cycles it will be necessary for the start-up script(s) to execute commands that require being enabled. If that requires putting an enable command with clear-text password into the startup script, that's not good.
-- Steve Good point.
How about allowing write access to event scripts on "/store" only in enabled mode and then generally run those scripts in enabled mode?
Regards, Michael
That works for me, though I thought that write access to anywhere in the file system already required Enable access, no? It was a bit of a surprise that the system event scripts weren't already run with "enable" privileges. User-level scripts (initiated by the CLI) should also require Enable access before starting them. We shouldn't ever need to have clear-text passwords in script files. What about Duktape scripts that can be called for Metric evaluation from the OBDII ECU Simulator? I can imagine that someone clever could odd things with specially crafted OBDII PID requests via pre-written scripts. But that would require access to the OBDII CAN Bus... Greg
On 25/02/18 11:24, Greg D. wrote:
Agree, WiFi's MAC is not useful as a passphrase or password, but I don't think that we need to go to blowing fuses to solve this.
Michael, you are absolutely right that we shouldn't leave an open wifi hotspot sitting there; it's an invitation for abuse. But if we have a static passphrase pre-set, and there is nothing one can do with the module in that state - plugged in but not configured - I think that the window for that abuse is going to be vanishingly small.
I think the concern here is someone plugging it in but never configuring it. The OVMS invites anyone passing to take control of it, which given it will trivially control the car, is something we should be careful with. For example, if you plug in and then forget about it, someone could come along and connect to the wifi and perform the initial configuration using the helpful web configuration wizard. Once they've configured the module, at least for some cars, they can simply use it to unlock the car. This scenario doesn't really require a targeted attack, as it's just stealing the vehicle or it's content, not trying cause the car to crash by loading malicious firmware. It doesn't require any skill as it's just using the standard OVMS features. Perhaps the module should give up if it doesn't get configured within say 30 minutes and shut off the access point and go to sleep. Alternatively we could put a big warning on the box "configure module as soon as possible"? Or both. The warning on it's own seems like a cop-out given we can limit the exposure with a timeout.
Since wifi can be either a client or an AP, not both, anyone using wifi for management can't use it as a client, since there is no easy way to move it back to being an AP. Ok, I suppose an SMS command could turn on AP mode... Is that the intent?
I've made some ESP8266 based data loggers that were both access point and station connected to another network at the same time. This wasn't intentional so I didn't spend long exploring how well it worked before turning off the access point.
Hi Tom, all, Ideally, sure, we could have a custom passphrase for each module, and have that written into flash and printed on the back of the module housing or on a printed card that comes in the box. If that can reasonably be provided in the manufacturing process flow, that would be great. But, I think, since the OVMS module will be a rather rare thing to see in the wild, that having a default wifi WPA2 passphrase will prevent all but the most devious and knowledgeable of passersby from getting into the module and messing around before its owner does. The passphrase - same for all modules - would only be on in a printed card that comes with the module, so as to not be discoverable online. I think that would be quite sufficient for this case, and would make recovery back to factory defaults a lot easier since there's nothing that has to be protected. And, we still avoid more fuse burning, which I think is a good thing. The idea of having a 30 minute AP mode disable if not configured would be fine. Overkill in my view, but if you think it's necessary, go for it. Greg Tom Parker wrote:
On 25/02/18 11:24, Greg D. wrote:
Agree, WiFi's MAC is not useful as a passphrase or password, but I don't think that we need to go to blowing fuses to solve this.
Michael, you are absolutely right that we shouldn't leave an open wifi hotspot sitting there; it's an invitation for abuse. But if we have a static passphrase pre-set, and there is nothing one can do with the module in that state - plugged in but not configured - I think that the window for that abuse is going to be vanishingly small.
I think the concern here is someone plugging it in but never configuring it. The OVMS invites anyone passing to take control of it, which given it will trivially control the car, is something we should be careful with. For example, if you plug in and then forget about it, someone could come along and connect to the wifi and perform the initial configuration using the helpful web configuration wizard. Once they've configured the module, at least for some cars, they can simply use it to unlock the car.
This scenario doesn't really require a targeted attack, as it's just stealing the vehicle or it's content, not trying cause the car to crash by loading malicious firmware. It doesn't require any skill as it's just using the standard OVMS features.
Perhaps the module should give up if it doesn't get configured within say 30 minutes and shut off the access point and go to sleep. Alternatively we could put a big warning on the box "configure module as soon as possible"? Or both. The warning on it's own seems like a cop-out given we can limit the exposure with a timeout.
Since wifi can be either a client or an AP, not both, anyone using wifi for management can't use it as a client, since there is no easy way to move it back to being an AP. Ok, I suppose an SMS command could turn on AP mode... Is that the intent?
I've made some ESP8266 based data loggers that were both access point and station connected to another network at the same time. This wasn't intentional so I didn't spend long exploring how well it worked before turning off the access point.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
The ESP32 supports AP-STA mode. I just hadn’t bothered supporting it in the wifi driver. Regards, Mark.
On 25 Feb 2018, at 3:43 PM, Tom Parker <tom@carrott.org> wrote:
On 25/02/18 11:24, Greg D. wrote: Since wifi can be either a client or an AP, not both, anyone using wifi
for management can't use it as a client, since there is no easy way to move it back to being an AP. Ok, I suppose an SMS command could turn on AP mode... Is that the intent?
I've made some ESP8266 based data loggers that were both access point and station connected to another network at the same time. This wasn't intentional so I didn't spend long exploring how well it worked before turning off the access point.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
You're right, the MAC would be nonsense. Tom nailed my concern, and all workarounds can be avoided by an individual pass phrase. Mark, couldn't it be sufficient to just set the pass phrase config value during QC instead of burning it into an eFuse? As the QC procedure should already involve a boot, it would just need to also issue a config command to the running module. With stickers printed at the QC station, the station could issue the command automatically, or with a pre-printed batch of stickers, the code could be scanned from the sticker to avoid manual entry. A later factory reset could also leave this config untouched, so it would only get cleared on an explicit flash erase -- and we can hook into the make targets to tell the user about this. Or am I missing something? Regards, Michael Am 24.02.2018 um 23:24 schrieb Greg D.:
Agree, WiFi's MAC is not useful as a passphrase or password, but I don't think that we need to go to blowing fuses to solve this.
Michael, you are absolutely right that we shouldn't leave an open wifi hotspot sitting there; it's an invitation for abuse. But if we have a static passphrase pre-set, and there is nothing one can do with the module in that state - plugged in but not configured - I think that the window for that abuse is going to be vanishingly small. A new customer will get the module and plug it in to either their car or (perhaps better) a standalone USB power source, and then configure it. It won't be left powered but unconfigured for very long. A new wifi AP passphrase can be set during that configuration process (encouraged or enforced), and the issue closed.
Especially these days, the most universally accepted means to configure something is with a web server. What you have done with the OVMS web server is very well designed and executed, and I don't see any significant issues with using that approach as the primary means for configuring and managing the module.
Greg
Mark Webb-Johnson wrote:
I’m not sure that Wifi MAC helps. That is broadcast as part of the WiFi station announcement, so using it as the password is really not any more secure than a fixed OVMS password.
Printing the wifi MAC also would be troublesome, because it would have to be entered into some printing program, and labels individually printed. Messy. Hand-written would not be good.
A better approach would be to come at it from the other way. Have the serial numbers / password stickers pre-printed in a large batch. Then, have the factory enter them into the number into the module during initial flashing / QC tests.
There is BLK3 of eFuses, but I find those scary. Supposedly it is not used (other than for a custom MAC address), and there are 192/256 bits available. That would be a one-time flash. We could store the serial number as a locally administered MAC address there.
It could also go into the flash as a configured parameter. That would be read/write (allowing someone to change the serial number).
BLK3 is probably the correct way of doing things, but very scary. That is a one time write (it literally sends too much current down a little wire in the chip - burning it out), and not so easy to debug the code ;-)
Regards, Mark.
On 24 Feb 2018, at 5:21 PM, Michael Balzer <dexter@expeedo.de> wrote:
Greg, Mark,
I'm a bit concerned about an initially open Wifi access.
I know we're not targeting a mass market, but security is always important, especially for a system that can potentially control a car.
We need to be -and stay- aware this may introduce a way to hack & hijack the system. You would for example scan for new OVMS wifi networks, do an automatic passkey change to get access, then get the module to install a trojan firmware that mimicks the original behaviour (root kit style) and voila, you've got another bitcoin miner. A normal user will never recognize something's fishy.
With our current OTA function that's an unlikely attack vector, you would need to either control the GSM cell / DNS to redirect the download to your trojan site or have hacked the openvehicles.com server to deliver your trojan firmware. But things will evolve.
Some users may also not care about the Wifi access (i.e. using just Bluetooth / USB / GSM) and then not be aware it's actually active & open.
Is it too expensive to print the Wifi MAC or serial no. onto some label or document for the user?
If so we should at least make this very clear in the user documentation.
Btw, the same password could be used as the default module password, or we could use the module password for both purposes.
Regards, Michael
Am 22.02.2018 um 05:52 schrieb Mark Webb-Johnson:
There probably isn't a need for a custom SSID based on MAC or other serialization; that would only be necessary if configuring multiple modules at the same time in the same place. Use case? Yep. My thoughts exactly.
it might be a good idea to have a required step of the configuration procedure be to force a passkey change and re-connect on the part of the user. Yep. If we ask them to specify the AP name, and new password, then that resolves both problems.
-- 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
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, couldn't it be sufficient to just set the pass phrase config value during QC instead of burning it into an eFuse?
I’ve asked the China side. Specifically: Can you print serial number stickers for these modules? I can provide design - and we can print a large batch. Then, during manufacturing, have one step to enter serial number as password into module, like: Flash Connect terminal QC checks New step to type: config set wifi.ap OVMS <serialnumber> I’ll let you know what they say. It should be fine, as it is just another part of the QC steps we are laying out for them. They are producing these in batches of one to two hundred, so just not feasible to automate too much. I just worry they’ll mis-type the serial number or something like that. Regards, Mark.
On 25 Feb 2018, at 7:05 PM, Michael Balzer <dexter@expeedo.de> wrote:
You're right, the MAC would be nonsense. Tom nailed my concern, and all workarounds can be avoided by an individual pass phrase.
Mark, couldn't it be sufficient to just set the pass phrase config value during QC instead of burning it into an eFuse?
As the QC procedure should already involve a boot, it would just need to also issue a config command to the running module. With stickers printed at the QC station, the station could issue the command automatically, or with a pre-printed batch of stickers, the code could be scanned from the sticker to avoid manual entry.
A later factory reset could also leave this config untouched, so it would only get cleared on an explicit flash erase -- and we can hook into the make targets to tell the user about this.
Or am I missing something?
Regards, Michael
Am 24.02.2018 um 23:24 schrieb Greg D.:
Agree, WiFi's MAC is not useful as a passphrase or password, but I don't think that we need to go to blowing fuses to solve this.
Michael, you are absolutely right that we shouldn't leave an open wifi hotspot sitting there; it's an invitation for abuse. But if we have a static passphrase pre-set, and there is nothing one can do with the module in that state - plugged in but not configured - I think that the window for that abuse is going to be vanishingly small. A new customer will get the module and plug it in to either their car or (perhaps better) a standalone USB power source, and then configure it. It won't be left powered but unconfigured for very long. A new wifi AP passphrase can be set during that configuration process (encouraged or enforced), and the issue closed.
Especially these days, the most universally accepted means to configure something is with a web server. What you have done with the OVMS web server is very well designed and executed, and I don't see any significant issues with using that approach as the primary means for configuring and managing the module.
Greg
Mark Webb-Johnson wrote:
I’m not sure that Wifi MAC helps. That is broadcast as part of the WiFi station announcement, so using it as the password is really not any more secure than a fixed OVMS password.
Printing the wifi MAC also would be troublesome, because it would have to be entered into some printing program, and labels individually printed. Messy. Hand-written would not be good.
A better approach would be to come at it from the other way. Have the serial numbers / password stickers pre-printed in a large batch. Then, have the factory enter them into the number into the module during initial flashing / QC tests.
There is BLK3 of eFuses, but I find those scary. Supposedly it is not used (other than for a custom MAC address), and there are 192/256 bits available. That would be a one-time flash. We could store the serial number as a locally administered MAC address there.
It could also go into the flash as a configured parameter. That would be read/write (allowing someone to change the serial number).
BLK3 is probably the correct way of doing things, but very scary. That is a one time write (it literally sends too much current down a little wire in the chip - burning it out), and not so easy to debug the code ;-)
Regards, Mark.
On 24 Feb 2018, at 5:21 PM, Michael Balzer <dexter@expeedo.de> wrote:
Greg, Mark,
I'm a bit concerned about an initially open Wifi access.
I know we're not targeting a mass market, but security is always important, especially for a system that can potentially control a car.
We need to be -and stay- aware this may introduce a way to hack & hijack the system. You would for example scan for new OVMS wifi networks, do an automatic passkey change to get access, then get the module to install a trojan firmware that mimicks the original behaviour (root kit style) and voila, you've got another bitcoin miner. A normal user will never recognize something's fishy.
With our current OTA function that's an unlikely attack vector, you would need to either control the GSM cell / DNS to redirect the download to your trojan site or have hacked the openvehicles.com server to deliver your trojan firmware. But things will evolve.
Some users may also not care about the Wifi access (i.e. using just Bluetooth / USB / GSM) and then not be aware it's actually active & open.
Is it too expensive to print the Wifi MAC or serial no. onto some label or document for the user?
If so we should at least make this very clear in the user documentation.
Btw, the same password could be used as the default module password, or we could use the module password for both purposes.
Regards, Michael
Am 22.02.2018 um 05:52 schrieb Mark Webb-Johnson:
There probably isn't a need for a custom SSID based on MAC or other serialization; that would only be necessary if configuring multiple modules at the same time in the same place. Use case? Yep. My thoughts exactly.
it might be a good idea to have a required step of the configuration procedure be to force a passkey change and re-connect on the part of the user. Yep. If we ask them to specify the AP name, and new password, then that resolves both problems.
-- 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
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
Mark, Am 26.02.2018 um 07:28 schrieb Mark Webb-Johnson:
I’ve asked the China side. Specifically:
1. Can you print serial number stickers for these modules? I can provide design - and we can print a large batch. 2. Then, during manufacturing, have one step to enter serial number as password into module, like: 1. Flash 2. Connect terminal 3. QC checks 4. New step to type: config set wifi.ap OVMS <serialnumber>
Just to double check: so we won't set the module password, only the AP pass phrase? Has setting the module password any drawbacks? I'm asking because I assume the SMS channel -as soon as implemented- will also provide command access, which would be open by default as well without a module password. Setting the module password would secure the webserver as well. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
They’ll do pretty much whatever we ask them to do. To try to formalise this, so everyone can see, I’ve created a production/qc/production_notes.txt file with the production notes that will be given to the China side. This should document all the production and QC steps they should do. What I have at the moment is: ******************************************************************************** ** TOOLS ******************************************************************************** 1] DB9 CAN Bus QC tool DB9 Female with: * Pins 2, 4, and 6 connected (all CAN-L signals) * Pins 5, 7, and 8 connected (all CAN-H signals) * R120 between pins 2 and 5 * External 12V power connector * GND on pin 3 * +12V on pin 9 ******************************************************************************** ** PRODUCTION STEPS ******************************************************************************** 1] Default wifi AP and module passwords OVMS> config set wifi.ap OVMS <serialnumber> OVMS> config set password module <serialnumber> Where <serialnumber> is the serial number from the label on the enclosure. I think that should set both the module default and auto wifi AP passwords to the serial number of the module. That will be on a label on the underside of the module. You are correct: this is a connected car, with possibly disastrous consequences should somebody malicious gain access. Best to err on the side of caution. Regards, Mark.
On 3 Mar 2018, at 4:07 AM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
Am 26.02.2018 um 07:28 schrieb Mark Webb-Johnson:
I’ve asked the China side. Specifically:
Can you print serial number stickers for these modules? I can provide design - and we can print a large batch. Then, during manufacturing, have one step to enter serial number as password into module, like: Flash Connect terminal QC checks New step to type: config set wifi.ap OVMS <serialnumber>
Just to double check: so we won't set the module password, only the AP pass phrase?
Has setting the module password any drawbacks?
I'm asking because I assume the SMS channel -as soon as implemented- will also provide command access, which would be open by default as well without a module password.
Setting the module password would secure the webserver as well.
Regards, Michael
-- 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
Plan is as follows: Serial numbers are of the form: YYYYBBNNNNN * YYYY is four digit year. For example; 2018 * BB is two digit batch. For example; 00, 01, 02, etc * NNNN is four digit sequence. For example; 0001, 0002, etc First production batch is 2018010001 - 2018010120. That would be 10 digits. Not the most secure, and pretty predictable, but better than a simple “OVMS”. I’m asking if the software they have can generate random characters. If it can, then will add four random letters onto the end. Regards, Mark.
On 4 Mar 2018, at 11:23 AM, Greg D. <gregd2350@gmail.com> wrote:
Hi Mark,
WPA2 PSK passphrases for WiFi need to be at least 8 characters. Do the serial numbers have leading zeros?
Greg
Mark Webb-Johnson wrote:
They’ll do pretty much whatever we ask them to do.
To try to formalise this, so everyone can see, I’ve created a production/qc/production_notes.txt file with the production notes that will be given to the China side. This should document all the production and QC steps they should do.
What I have at the moment is:
******************************************************************************** ** TOOLS ********************************************************************************
1] DB9 CAN Bus QC tool
DB9 Female with: * Pins 2, 4, and 6 connected (all CAN-L signals) * Pins 5, 7, and 8 connected (all CAN-H signals) * R120 between pins 2 and 5 * External 12V power connector * GND on pin 3 * +12V on pin 9
******************************************************************************** ** PRODUCTION STEPS ********************************************************************************
1] Default wifi AP and module passwords
OVMS> config set wifi.ap OVMS <serialnumber> OVMS> config set password module <serialnumber>
Where <serialnumber> is the serial number from the label on the enclosure.
I think that should set both the module default and auto wifi AP passwords to the serial number of the module. That will be on a label on the underside of the module.
You are correct: this is a connected car, with possibly disastrous consequences should somebody malicious gain access. Best to err on the side of caution.
Regards, Mark.
On 3 Mar 2018, at 4:07 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
Am 26.02.2018 um 07:28 schrieb Mark Webb-Johnson:
I’ve asked the China side. Specifically:
Can you print serial number stickers for these modules? I can provide design - and we can print a large batch. Then, during manufacturing, have one step to enter serial number as password into module, like: Flash Connect terminal QC checks New step to type: config set wifi.ap OVMS <serialnumber>
Just to double check: so we won't set the module password, only the AP pass phrase?
Has setting the module password any drawbacks?
I'm asking because I assume the SMS channel -as soon as implemented- will also provide command access, which would be open by default as well without a module password.
Setting the module password would secure the webserver as well.
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ 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
Just got a file in my eMail from factory. First 120 serial numbers. Like this: 2018010014ABCD (last four characters redacted) Very nice, and should work well. If we keep it quiet, the users will start an online discussion topic about the mysterious encoding in the last four characters of the serial number and what it means. I also realised that those 120 lines in the file are a master password list for the OVMS modules! A hacker’s delight. Regards, Mark.
On 4 Mar 2018, at 12:35 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Plan is as follows:
Serial numbers are of the form:
YYYYBBNNNNN
* YYYY is four digit year. For example; 2018 * BB is two digit batch. For example; 00, 01, 02, etc * NNNN is four digit sequence. For example; 0001, 0002, etc
First production batch is 2018010001 - 2018010120.
That would be 10 digits. Not the most secure, and pretty predictable, but better than a simple “OVMS”.
I’m asking if the software they have can generate random characters. If it can, then will add four random letters onto the end.
Regards, Mark.
On 4 Mar 2018, at 11:23 AM, Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>> wrote:
Hi Mark,
WPA2 PSK passphrases for WiFi need to be at least 8 characters. Do the serial numbers have leading zeros?
Greg
Mark Webb-Johnson wrote:
They’ll do pretty much whatever we ask them to do.
To try to formalise this, so everyone can see, I’ve created a production/qc/production_notes.txt file with the production notes that will be given to the China side. This should document all the production and QC steps they should do.
What I have at the moment is:
******************************************************************************** ** TOOLS ********************************************************************************
1] DB9 CAN Bus QC tool
DB9 Female with: * Pins 2, 4, and 6 connected (all CAN-L signals) * Pins 5, 7, and 8 connected (all CAN-H signals) * R120 between pins 2 and 5 * External 12V power connector * GND on pin 3 * +12V on pin 9
******************************************************************************** ** PRODUCTION STEPS ********************************************************************************
1] Default wifi AP and module passwords
OVMS> config set wifi.ap OVMS <serialnumber> OVMS> config set password module <serialnumber>
Where <serialnumber> is the serial number from the label on the enclosure.
I think that should set both the module default and auto wifi AP passwords to the serial number of the module. That will be on a label on the underside of the module.
You are correct: this is a connected car, with possibly disastrous consequences should somebody malicious gain access. Best to err on the side of caution.
Regards, Mark.
On 3 Mar 2018, at 4:07 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
Am 26.02.2018 um 07:28 schrieb Mark Webb-Johnson:
I’ve asked the China side. Specifically:
Can you print serial number stickers for these modules? I can provide design - and we can print a large batch. Then, during manufacturing, have one step to enter serial number as password into module, like: Flash Connect terminal QC checks New step to type: config set wifi.ap OVMS <serialnumber>
Just to double check: so we won't set the module password, only the AP pass phrase?
Has setting the module password any drawbacks?
I'm asking because I assume the SMS channel -as soon as implemented- will also provide command access, which would be open by default as well without a module password.
Setting the module password would secure the webserver as well.
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ 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
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
The vulnerability is the open access point, up until the time the user changes the password. @Michael: Can we extend webserver to show a screen prompting for password change, when user logs in, if the current password is of the format: 20\d{8,8}\w{4,4}. Either that, or have a config setting to record that password has been changed, and keep prompting that change password screen, on login, until it has been set (then clear the flag). Change both the module and default wifi password to whatever is entered? Firmware deadline for first production is Monday 19th March 2018, so I’ll tag the code on Sunday with wherever we are and build based on that. We always have OTA ... Regards, Mark.
On 15 Mar 2018, at 1:32 AM, Greg D. <gregd2350@gmail.com> wrote:
Interesting. But the "hacker's delight" risk is only with physical access to the module, in order to reset it back to factory (somehow). Once the module's password is changed by the owner, knowing the "master password" is useless. Right?
Greg
Mark Webb-Johnson wrote:
Just got a file in my eMail from factory. First 120 serial numbers. Like this:
2018010014ABCD (last four characters redacted)
Very nice, and should work well. If we keep it quiet, the users will start an online discussion topic about the mysterious encoding in the last four characters of the serial number and what it means.
I also realised that those 120 lines in the file are a master password list for the OVMS modules! A hacker’s delight.
Regards, Mark.
On 4 Mar 2018, at 12:35 PM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
Plan is as follows:
Serial numbers are of the form:
YYYYBBNNNNN
* YYYY is four digit year. For example; 2018 * BB is two digit batch. For example; 00, 01, 02, etc * NNNN is four digit sequence. For example; 0001, 0002, etc
First production batch is 2018010001 - 2018010120.
That would be 10 digits. Not the most secure, and pretty predictable, but better than a simple “OVMS”.
I’m asking if the software they have can generate random characters. If it can, then will add four random letters onto the end.
Regards, Mark.
On 4 Mar 2018, at 11:23 AM, Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>> wrote:
Hi Mark,
WPA2 PSK passphrases for WiFi need to be at least 8 characters. Do the serial numbers have leading zeros?
Greg
Mark Webb-Johnson wrote:
They’ll do pretty much whatever we ask them to do.
To try to formalise this, so everyone can see, I’ve created a production/qc/production_notes.txt file with the production notes that will be given to the China side. This should document all the production and QC steps they should do.
What I have at the moment is:
******************************************************************************** ** TOOLS ********************************************************************************
1] DB9 CAN Bus QC tool
DB9 Female with: * Pins 2, 4, and 6 connected (all CAN-L signals) * Pins 5, 7, and 8 connected (all CAN-H signals) * R120 between pins 2 and 5 * External 12V power connector * GND on pin 3 * +12V on pin 9
******************************************************************************** ** PRODUCTION STEPS ********************************************************************************
1] Default wifi AP and module passwords
OVMS> config set wifi.ap OVMS <serialnumber> OVMS> config set password module <serialnumber>
Where <serialnumber> is the serial number from the label on the enclosure.
I think that should set both the module default and auto wifi AP passwords to the serial number of the module. That will be on a label on the underside of the module.
You are correct: this is a connected car, with possibly disastrous consequences should somebody malicious gain access. Best to err on the side of caution.
Regards, Mark.
On 3 Mar 2018, at 4:07 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
Am 26.02.2018 um 07:28 schrieb Mark Webb-Johnson: > > I’ve asked the China side. Specifically: > > Can you print serial number stickers for these modules? I can provide design - and we can print a large batch. > Then, during manufacturing, have one step to enter serial number as password into module, like: > Flash > Connect terminal > QC checks > New step to type: config set wifi.ap OVMS <serialnumber>
Just to double check: so we won't set the module password, only the AP pass phrase?
Has setting the module password any drawbacks?
I'm asking because I assume the SMS channel -as soon as implemented- will also provide command access, which would be open by default as well without a module password.
Setting the module password would secure the webserver as well.
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ 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
Am 15.03.2018 um 05:37 schrieb Mark Webb-Johnson:
@Michael: Can we extend webserver to show a screen prompting for password change, when user logs in, if the current password is of the format: 20\d{8,8}\w{4,4}. Either that, or have a config setting to record that password has been changed, and keep prompting that change password screen, on login, until it has been set (then clear the flag). Change both the module and default wifi password to whatever is entered?
Pushed, please test. If you want to get rid of the warning & redirect without changing your password, do: config set password changed yes Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Mark,
******************************************************************************** ** PRODUCTION STEPS ********************************************************************************
1] Default wifi AP and module passwords
OVMS> config set wifi.ap OVMS <serialnumber> OVMS> config set password module <serialnumber>
Where <serialnumber> is the serial number from the label on the enclosure.
We should add… OVMS> config set modem apn hologram …so the Hologram SIM can work out of the box. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Yep. Thanks. Mark
On 18 Mar 2018, at 7:57 PM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
******************************************************************************** ** PRODUCTION STEPS ********************************************************************************
1] Default wifi AP and module passwords
OVMS> config set wifi.ap OVMS <serialnumber> OVMS> config set password module <serialnumber>
Where <serialnumber> is the serial number from the label on the enclosure.
We should add…
OVMS> config set modem apn hologram
…so the Hologram SIM can work out of the box.
Regards, Michael
-- 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
Am 24.02.2018 um 23:24 schrieb Greg D.:
I spent a few minutes playing with it just now, and I think there are a couple of extensions that would complete the package. The biggest disconnect I see between the webserver and CLI management approaches is the role of files. They are central to the CLI, with little files sprinkled everywhere about the module. For the config items, that's well handled by both methods, but for events, that's a problem. Perhaps this is coming, but I currently don't see where the file tree is visible, nor a facility for creating and editing them. Are these planned, or is there a different means for managing on-board files?
Files and directory listings are currently already accessible and enabled by default (see configuration). The default docroot is "/sd". If you enter a URL that is not handled by the webserver framework, it will be served from the SD card. If the URL is a directory, you'll get the file list. See my initial post on the web frontend for details. I suppose you mean scripts by files related to events. A script editor is on my list -- low prio, I see scripts as power user tools. A normal user should be done by configuring the intended behaviour. Scripts currently are necessary because some standard automatics are not yet implemented.
Finally, a use-case question. Do we expect folks to be using the wifi client along with the modem, for example, using the wifi connection while at home or work to reduce cellular data fees, with the module flipping over to cellular when on the road? I guess there are two reasons for asking... First to understand what the connectivity and management scenarios are, and second, the known difficulty in flipping between the two connection stacks.
Since wifi can be either a client or an AP, not both, anyone using wifi for management can't use it as a client, since there is no easy way to move it back to being an AP. Ok, I suppose an SMS command could turn on AP mode... Is that the intent?
I think we should implement the combined AP-STA mode as well and solve the issues with switching between modem and wifi. I'll try to use both access ways simultaneously, as I want the module to transmit telemetry to the server by GSM while providing the web console via Wifi to my mobile phone to avoid the latency involved by the server path. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Btw: a friend of mine also asked if he'll be able to use the module as an internet gateway -- I think that should be possible, there seems to be packet forwarding / routing support in the stack. Am 25.02.2018 um 12:52 schrieb Michael Balzer:
I think we should implement the combined AP-STA mode as well and solve the issues with switching between modem and wifi.
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Perhaps yes, but why? If the objective is to eliminate having multiple SIMs and associated payment (a worthy objective!), I think it would be better / safer to put the one SIM in a mobile hotspot, and let everyone (OVMS and other clients) connect to that. That's what I am testing with the SyncUp OBDII Dongle and the OBD2ECU task, and it seems to work. The only issue I have is knowing when it is safe to turn off the Dongle's power, and then how to turn it back on again. I'm not sure it's low enough power to just be on all the time, even given that all / most / some EVs (yes?) have 12v systems that are refreshed automatically from the main (BIG) battery pack. The ovms module seems to run about 60ma; the SyncUp dongle adds another 150ma on top of that. How much drain is too much? Greg Michael Balzer wrote:
Btw: a friend of mine also asked if he'll be able to use the module as an internet gateway -- I think that should be possible, there seems to be packet forwarding / routing support in the stack.
Am 25.02.2018 um 12:52 schrieb Michael Balzer:
I think we should implement the combined AP-STA mode as well and solve the issues with switching between modem and wifi.
On Sun, 25 Feb 2018, Greg D. wrote:
Perhaps yes, but why?
If the objective is to eliminate having multiple SIMs and associated payment (a worthy objective!), I think it would be better / safer to put the one SIM in a mobile hotspot, and let everyone (OVMS and other clients) connect to that. That's what I am testing with the SyncUp OBDII Dongle and the OBD2ECU task, and it seems to work.
If OVMS can be the hotspot, then you don't have to buy and install a hotspot. You would need to choose an appropriate SIM card and plan.
The only issue I have is knowing when it is safe to turn off the Dongle's power, and then how to turn it back on again. I'm not sure it's low enough power to just be on all the time, even given that all / most / some EVs (yes?) have 12v systems that are refreshed automatically from the main (BIG) battery pack. The ovms module seems to run about 60ma; the SyncUp dongle adds another 150ma on top of that. How much drain is too much?
The problem is that many EV's don't recharge the 12V battery unless the car is turned on. This dates back at least to the 2002/3 RAV4-EV (of which we have one) for which "dead 12V battery" was the most common cause of failure to run. -- Steve
Hi Steve,
The problem is that many EV's don't recharge the 12V battery unless the car is turned on. This dates back at least to the 2002/3 RAV4-EV (of which we have one) for which "dead 12V battery" was the most common cause of failure to run.
Ah, ok. I wasn't sure of the general case. There are videos of folks using the 12v battery in a Nissan Leaf to run an inverter during a power outage, with the car automatically topping it off as needed. My own Roadster seems to keep the 12v battery at a constant 13.77v, no matter what the car is doing (on, awake, asleep, charging, etc.). Never seems to vary more than 10mv or so, which is really odd, given that the car should be running off just the 12v battery when it's asleep (it's a 2.0). I asked about it at my last annual service, and the service manager (one of the original Roadster techs) couldn't explain it. A small 12v car battery probably wouldn't mind the 60ma the ovms module draws by itself. I don't know what a typical hotspot draws, but if it's similar, bumping that to just over 200 ma with the SyncUp dongle is probably too much.
If OVMS can be the hotspot, then you don't have to buy and install a hotspot. You would need to choose an appropriate SIM card and plan.
Yes, that's the use case. I guess I'd rather keep the OVMS module's processor bandwidth focused on its primary task, and not have odd traffic trying to run through it to the modem, potentially exposing otherwise-dormant protocol or timing bugs. Do we really have all that much extra CPU power? Is there a way to throttle the pass-through traffic in order to keep things stable (or is the modem doing enough of that for us by virtue of its cellular connection)? Greg Stephen Casner wrote:
On Sun, 25 Feb 2018, Greg D. wrote:
Perhaps yes, but why?
If the objective is to eliminate having multiple SIMs and associated payment (a worthy objective!), I think it would be better / safer to put the one SIM in a mobile hotspot, and let everyone (OVMS and other clients) connect to that. That's what I am testing with the SyncUp OBDII Dongle and the OBD2ECU task, and it seems to work. If OVMS can be the hotspot, then you don't have to buy and install a hotspot. You would need to choose an appropriate SIM card and plan.
The only issue I have is knowing when it is safe to turn off the Dongle's power, and then how to turn it back on again. I'm not sure it's low enough power to just be on all the time, even given that all / most / some EVs (yes?) have 12v systems that are refreshed automatically from the main (BIG) battery pack. The ovms module seems to run about 60ma; the SyncUp dongle adds another 150ma on top of that. How much drain is too much? The problem is that many EV's don't recharge the 12V battery unless the car is turned on. This dates back at least to the 2002/3 RAV4-EV (of which we have one) for which "dead 12V battery" was the most common cause of failure to run.
-- Steve _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
It's a function available on most connected cars. The car can be used as the mobile hotspot (i.e. for tablets without SIM slots), no need for another box and separate SIM. Regards, Michael Am 26.02.2018 um 01:01 schrieb Greg D.:
Perhaps yes, but why?
If the objective is to eliminate having multiple SIMs and associated payment (a worthy objective!), I think it would be better / safer to put the one SIM in a mobile hotspot, and let everyone (OVMS and other clients) connect to that. That's what I am testing with the SyncUp OBDII Dongle and the OBD2ECU task, and it seems to work.
The only issue I have is knowing when it is safe to turn off the Dongle's power, and then how to turn it back on again. I'm not sure it's low enough power to just be on all the time, even given that all / most / some EVs (yes?) have 12v systems that are refreshed automatically from the main (BIG) battery pack. The ovms module seems to run about 60ma; the SyncUp dongle adds another 150ma on top of that. How much drain is too much?
Greg
Michael Balzer wrote:
Btw: a friend of mine also asked if he'll be able to use the module as an internet gateway -- I think that should be possible, there seems to be packet forwarding / routing support in the stack.
Am 25.02.2018 um 12:52 schrieb Michael Balzer:
I think we should implement the combined AP-STA mode as well and solve the issues with switching between modem and wifi.
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 connection modem<->esp32 is the limiting factor there. That is currently async 115,200 baud. Fine for our purposes, but pretty useless as a wifi hotspot. I guess the speed could be increased, but there is no hardware flow control. Not really the intended use case. Regards, Mark
On 25 Feb 2018, at 7:57 PM, Michael Balzer <dexter@expeedo.de> wrote:
Btw: a friend of mine also asked if he'll be able to use the module as an internet gateway -- I think that should be possible, there seems to be packet forwarding / routing support in the stack.
Am 25.02.2018 um 12:52 schrieb Michael Balzer:
I think we should implement the combined AP-STA mode as well and solve the issues with switching between modem and wifi.
-- 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
Oh… yes, haven't thought about that. Never mind, it's just a nice-to-have. Am 26.02.2018 um 06:56 schrieb Mark Webb-Johnson:
The connection modem<->esp32 is the limiting factor there. That is currently async 115,200 baud. Fine for our purposes, but pretty useless as a wifi hotspot.
I guess the speed could be increased, but there is no hardware flow control.
Not really the intended use case.
Regards, Mark
On 25 Feb 2018, at 7:57 PM, Michael Balzer <dexter@expeedo.de> wrote:
Btw: a friend of mine also asked if he'll be able to use the module as an internet gateway -- I think that should be possible, there seems to be packet forwarding / routing support in the stack.
Am 25.02.2018 um 12:52 schrieb Michael Balzer:
I think we should implement the combined AP-STA mode as well and solve the issues with switching between modem and wifi. -- 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
Am 22.02.2018 um 04:22 schrieb Mark Webb-Johnson:
When looking at the deep sleep stuff, I found there is a way to tag a global variable as ‘rtc’. That should survive a deep sleep (or reboot).
Unfortunately, it does not survive a reboot:
* Data in RTC memory is initialised whenever the SoC restarts, except when waking from deep sleep. When waking from deep sleep, the values which were present before going to sleep are kept.
There is an NVS library: https://esp-idf.readthedocs.io/en/v1.0/api/nvs_flash.html …but I've got the impression that could interfere with our own flash usage (?). Also, if flash is the way and as /store is already present at housekeeping init, I think we can just as well use our own config module… Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
First version of the auto init system is in the hub. As discussed, I added an "auto" config param. It currently has these instances: Instance Default Remark ---------------------------------------------------------------------- init yes wifi.mode ap off|ap|client wifi.ssid.ap OVMS wifi.ssid.client - empty = scanning mode modem no vehicle.type - moved from vehicle/type server.v2 no server.v3 no The web UI has a new config page for this as well. On boot, the housekeeper temporarily sets "init" to false. 10 seconds after booting has finished it re-enables it, assuming the system is stable. The auto wifi ap mode does a fallback to "OVMS" with the module password if no AP network is configured. It does not start the AP mode if the password is empty. So in order to enable the AP mode for configuration, it's sufficient to set the module password and leave all auto configs to their defaults. Unfortunately a crash reboot seems to be indistinguishable from a manual reset. I've added a log output of the reset reason provided by the ESP. The reason codes are: typedef enum { NO_MEAN = 0, POWERON_RESET = 1, /**<1, Vbat power on reset*/ SW_RESET = 3, /**<3, Software reset digital core*/ OWDT_RESET = 4, /**<4, Legacy watch dog reset digital core*/ DEEPSLEEP_RESET = 5, /**<3, Deep Sleep reset digital core*/ SDIO_RESET = 6, /**<6, Reset by SLC module, reset digital core*/ TG0WDT_SYS_RESET = 7, /**<7, Timer Group0 Watch dog reset digital core*/ TG1WDT_SYS_RESET = 8, /**<8, Timer Group1 Watch dog reset digital core*/ RTCWDT_SYS_RESET = 9, /**<9, RTC Watch dog Reset digital core*/ INTRUSION_RESET = 10, /**<10, Instrusion tested to reset CPU*/ TGWDT_CPU_RESET = 11, /**<11, Time Group reset CPU*/ SW_CPU_RESET = 12, /**<12, Software reset CPU*/ RTCWDT_CPU_RESET = 13, /**<13, RTC Watch dog Reset CPU*/ EXT_CPU_RESET = 14, /**<14, for APP CPU, reseted by PRO CPU*/ RTCWDT_BROWN_OUT_RESET = 15, /**<15, Reset when the vdd voltage is not stable*/ RTCWDT_RTC_RESET = 16 /**<16, RTC Watch dog reset digital core and rtc module*/ } RESET_REASON; I get these values: …boot after make app-flash: I (537) housekeeping: reset_reason: cpu0=1, cpu1=14 …after triggering vfs-edit-bug: I (527) housekeeping: reset_reason: cpu0=12, cpu1=12 …after "module reset": I (527) housekeeping: reset_reason: cpu0=12, cpu1=12 …after "module fault": I (527) housekeeping: reset_reason: cpu0=12, cpu1=12 …and no, the 12/12 were not sticky, I checked with a clean boot. There's also a bug in the ESP32 that may trigger false positives: https://github.com/espressif/esp-idf/issues/494#issuecomment-291916959 I haven't had that effect up to now, but it seems we cannot rely on the reset reason. Regards, Michael Am 25.02.2018 um 15:06 schrieb Michael Balzer:
Am 22.02.2018 um 04:22 schrieb Mark Webb-Johnson:
When looking at the deep sleep stuff, I found there is a way to tag a global variable as ‘rtc’. That should survive a deep sleep (or reboot). Unfortunately, it does not survive a reboot:
* Data in RTC memory is initialised whenever the SoC restarts, except when waking from deep sleep. When waking from deep sleep, the values which were present before going to sleep are kept. There is an NVS library: https://esp-idf.readthedocs.io/en/v1.0/api/nvs_flash.html
…but I've got the impression that could interfere with our own flash usage (?).
Also, if flash is the way and as /store is already present at housekeeping init, I think we can just as well use our own config module…
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
I understand the desire for security, but how does one set the password the first time? Instead, how about about using a default passkey if the module password is not set? That keeps the web interface closed to the casual passerby, but allows initial connection to those with the physical module's accompanying documentation. We really ought to be making this easier to configure than the v2 module, where it one needed wrestle with SIM cards, accounts, and activation headaches in order use SMS messages. USB serial consoles are better, but they still aren't all that user friendly. We have a wonderful web interface; we should be able to use it out of the box. Greg Michael Balzer wrote:
The auto wifi ap mode does a fallback to "OVMS" with the module password if no AP network is configured. It does not start the AP mode if the password is empty. So in order to enable the AP mode for configuration, it's sufficient to set the module password and leave all auto configs to their defaults.
Greg, this handling is based on the assumption we can have the QC set the initial pass phrase / module password. It also protects a power user / developer against forgetting to configure a pass phrase after a full reflash of the module. Normal users will update OTA / by SD card, so will not lose the pass phrase once set. Let's see if QC can do that. If not, we can fallback to a default password instead. Regards, Michael Am 26.02.2018 um 01:46 schrieb Greg D.:
I understand the desire for security, but how does one set the password the first time? Instead, how about about using a default passkey if the module password is not set? That keeps the web interface closed to the casual passerby, but allows initial connection to those with the physical module's accompanying documentation.
We really ought to be making this easier to configure than the v2 module, where it one needed wrestle with SIM cards, accounts, and activation headaches in order use SMS messages. USB serial consoles are better, but they still aren't all that user friendly. We have a wonderful web interface; we should be able to use it out of the box.
Greg
Michael Balzer wrote:
The auto wifi ap mode does a fallback to "OVMS" with the module password if no AP network is configured. It does not start the AP mode if the password is empty. So in order to enable the AP mode for configuration, it's sufficient to set the module password and leave all auto configs to their defaults.
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
Sounds good. Fingers crossed that QC can do it; if not, we still have a reasonable plan. Greg Michael Balzer wrote:
Greg,
this handling is based on the assumption we can have the QC set the initial pass phrase / module password.
It also protects a power user / developer against forgetting to configure a pass phrase after a full reflash of the module.
Normal users will update OTA / by SD card, so will not lose the pass phrase once set.
Let's see if QC can do that. If not, we can fallback to a default password instead.
Regards, Michael
Am 26.02.2018 um 01:46 schrieb Greg D.:
I understand the desire for security, but how does one set the password the first time? Instead, how about about using a default passkey if the module password is not set? That keeps the web interface closed to the casual passerby, but allows initial connection to those with the physical module's accompanying documentation.
We really ought to be making this easier to configure than the v2 module, where it one needed wrestle with SIM cards, accounts, and activation headaches in order use SMS messages. USB serial consoles are better, but they still aren't all that user friendly. We have a wonderful web interface; we should be able to use it out of the box.
Greg
Michael Balzer wrote:
The auto wifi ap mode does a fallback to "OVMS" with the module password if no AP network is configured. It does not start the AP mode if the password is empty. So in order to enable the AP mode for configuration, it's sufficient to set the module password and leave all auto configs to their defaults.
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Saw this one just now: Brownout detector was triggered ets Jun 8 2016 00:22:57 rst:0xc (SW_CPU_RESET),boot:0x3b (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:5984 ho 0 tail 12 room 4 load:0x40078000,len:0 load:0x40078000,len:15696 entry 0x4007901c I (30) boot: ESP-IDF v3.1-dev-430-gddeff7d5 2nd stage bootloader I (402) housekeeping: Initialising HOUSEKEEPING Framework... I (462) housekeeping: Executing on CPU core 1 I (462) housekeeping: reset_reason: cpu0=12, cpu1=12 (Not taking my own advise about powered USB hubs) Regards, Mark.
On 26 Feb 2018, at 3:51 AM, Michael Balzer <dexter@expeedo.de> wrote:
First version of the auto init system is in the hub.
As discussed, I added an "auto" config param. It currently has these instances:
Instance Default Remark ---------------------------------------------------------------------- init yes
wifi.mode ap off|ap|client wifi.ssid.ap OVMS wifi.ssid.client - empty = scanning mode
modem no
vehicle.type - moved from vehicle/type
server.v2 no server.v3 no
The web UI has a new config page for this as well.
On boot, the housekeeper temporarily sets "init" to false. 10 seconds after booting has finished it re-enables it, assuming the system is stable.
The auto wifi ap mode does a fallback to "OVMS" with the module password if no AP network is configured. It does not start the AP mode if the password is empty. So in order to enable the AP mode for configuration, it's sufficient to set the module password and leave all auto configs to their defaults.
Unfortunately a crash reboot seems to be indistinguishable from a manual reset. I've added a log output of the reset reason provided by the ESP. The reason codes are:
typedef enum { NO_MEAN = 0, POWERON_RESET = 1, /**<1, Vbat power on reset*/ SW_RESET = 3, /**<3, Software reset digital core*/ OWDT_RESET = 4, /**<4, Legacy watch dog reset digital core*/ DEEPSLEEP_RESET = 5, /**<3, Deep Sleep reset digital core*/ SDIO_RESET = 6, /**<6, Reset by SLC module, reset digital core*/ TG0WDT_SYS_RESET = 7, /**<7, Timer Group0 Watch dog reset digital core*/ TG1WDT_SYS_RESET = 8, /**<8, Timer Group1 Watch dog reset digital core*/ RTCWDT_SYS_RESET = 9, /**<9, RTC Watch dog Reset digital core*/ INTRUSION_RESET = 10, /**<10, Instrusion tested to reset CPU*/ TGWDT_CPU_RESET = 11, /**<11, Time Group reset CPU*/ SW_CPU_RESET = 12, /**<12, Software reset CPU*/ RTCWDT_CPU_RESET = 13, /**<13, RTC Watch dog Reset CPU*/ EXT_CPU_RESET = 14, /**<14, for APP CPU, reseted by PRO CPU*/ RTCWDT_BROWN_OUT_RESET = 15, /**<15, Reset when the vdd voltage is not stable*/ RTCWDT_RTC_RESET = 16 /**<16, RTC Watch dog reset digital core and rtc module*/ } RESET_REASON;
I get these values:
…boot after make app-flash: I (537) housekeeping: reset_reason: cpu0=1, cpu1=14
…after triggering vfs-edit-bug: I (527) housekeeping: reset_reason: cpu0=12, cpu1=12
…after "module reset": I (527) housekeeping: reset_reason: cpu0=12, cpu1=12
…after "module fault": I (527) housekeeping: reset_reason: cpu0=12, cpu1=12
…and no, the 12/12 were not sticky, I checked with a clean boot.
There's also a bug in the ESP32 that may trigger false positives: https://github.com/espressif/esp-idf/issues/494#issuecomment-291916959
I haven't had that effect up to now, but it seems we cannot rely on the reset reason.
Regards, Michael
Am 25.02.2018 um 15:06 schrieb Michael Balzer:
Am 22.02.2018 um 04:22 schrieb Mark Webb-Johnson:
When looking at the deep sleep stuff, I found there is a way to tag a global variable as ‘rtc’. That should survive a deep sleep (or reboot). Unfortunately, it does not survive a reboot:
* Data in RTC memory is initialised whenever the SoC restarts, except when waking from deep sleep. When waking from deep sleep, the values which were present before going to sleep are kept. There is an NVS library: https://esp-idf.readthedocs.io/en/v1.0/api/nvs_flash.html
…but I've got the impression that could interfere with our own flash usage (?).
Also, if flash is the way and as /store is already present at housekeeping init, I think we can just as well use our own config module…
Regards, Michael
-- 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
I’m having problems with this approach. Specifically, permanently disabling the auto start system if the system fails once during a boot. I tried the module in my car today. Plugged it in, but the access point didn’t come up. No laptop, just an iPad. It seems that while I was plugging it in, the power jiggled. So it booted for a second or so, reset, then booted again. It treated this as a problem, so turned off the auto init system permanently. No matter how many times I reset, I couldn’t get an access point to come up, and couldn’t get into the system from the iPad. I’m not sure that storing this in config (fat filesystem) is optimal. I think the core reason for that was because the ESP IDF framework wipes RTC memory on boot for anything apart from a deep sleep. So, I set about finding a solution to that core problem. The result is quite neat, and visible in main/component.mk, and main/ovms_boot.*. It turns out that the ESP framework (start_cpu0) wipes the RTC BSS segment only. It leaves other RTC data untouched. So... I create a linker section ‘.rtc.noload’. This goes in RTC slow ram, alongside the other RTC bss sections. But the NOLOAD flag is specified, to stop GCC from wiping this memory on boot. I then create a typedef struct boot_data_t and storage boot_data to store the actual boot data. It is tagged __attribute__((section(".rtc.noload"))) to force it into that NOLOAD section. I’ve now got some data that never gets initialised, and survives a reset. The last step is to check the actual boot reason (using rtc_get_reset_reason). If it is POWERON_RESET then I zero the boot_data storage (otherwise it is truly garbage - perhaps good for random number initialisation, but not much else). It seems to work well for me, and is a quite neat solution. I added a ‘boot status’ command to show the status of the last boot, including the count of reboots. Regarding differentiating between ‘module reset’ and another type of reset, I think we can now simply add a bool to boot_data_t and have ‘module reset’ set it before resetting. It can then be picked up during boot (reason SW_CPU_RESET, and check for this flag) to pickup on this specific case. If it is a SW_CPU_RESET and this flag is not set, then we can assume it was a crash. With this, I think we can do some more sophisticated logic. The ‘first ten seconds’ flag goes in boot_data_t. We can also keep a count of failure resets during first 10 seconds, and if it exceeds say 5 then turn off auto init (but with a setting just in ram, leaving the config 'auto init' to indicate whether the user wants init to be auto or not). Workable? Regards, Mark.
On 26 Feb 2018, at 3:51 AM, Michael Balzer <dexter@expeedo.de> wrote:
First version of the auto init system is in the hub.
As discussed, I added an "auto" config param. It currently has these instances:
Instance Default Remark ---------------------------------------------------------------------- init yes
wifi.mode ap off|ap|client wifi.ssid.ap OVMS wifi.ssid.client - empty = scanning mode
modem no
vehicle.type - moved from vehicle/type
server.v2 no server.v3 no
The web UI has a new config page for this as well.
On boot, the housekeeper temporarily sets "init" to false. 10 seconds after booting has finished it re-enables it, assuming the system is stable.
The auto wifi ap mode does a fallback to "OVMS" with the module password if no AP network is configured. It does not start the AP mode if the password is empty. So in order to enable the AP mode for configuration, it's sufficient to set the module password and leave all auto configs to their defaults.
Unfortunately a crash reboot seems to be indistinguishable from a manual reset. I've added a log output of the reset reason provided by the ESP. The reason codes are:
typedef enum { NO_MEAN = 0, POWERON_RESET = 1, /**<1, Vbat power on reset*/ SW_RESET = 3, /**<3, Software reset digital core*/ OWDT_RESET = 4, /**<4, Legacy watch dog reset digital core*/ DEEPSLEEP_RESET = 5, /**<3, Deep Sleep reset digital core*/ SDIO_RESET = 6, /**<6, Reset by SLC module, reset digital core*/ TG0WDT_SYS_RESET = 7, /**<7, Timer Group0 Watch dog reset digital core*/ TG1WDT_SYS_RESET = 8, /**<8, Timer Group1 Watch dog reset digital core*/ RTCWDT_SYS_RESET = 9, /**<9, RTC Watch dog Reset digital core*/ INTRUSION_RESET = 10, /**<10, Instrusion tested to reset CPU*/ TGWDT_CPU_RESET = 11, /**<11, Time Group reset CPU*/ SW_CPU_RESET = 12, /**<12, Software reset CPU*/ RTCWDT_CPU_RESET = 13, /**<13, RTC Watch dog Reset CPU*/ EXT_CPU_RESET = 14, /**<14, for APP CPU, reseted by PRO CPU*/ RTCWDT_BROWN_OUT_RESET = 15, /**<15, Reset when the vdd voltage is not stable*/ RTCWDT_RTC_RESET = 16 /**<16, RTC Watch dog reset digital core and rtc module*/ } RESET_REASON;
I get these values:
…boot after make app-flash: I (537) housekeeping: reset_reason: cpu0=1, cpu1=14
…after triggering vfs-edit-bug: I (527) housekeeping: reset_reason: cpu0=12, cpu1=12
…after "module reset": I (527) housekeeping: reset_reason: cpu0=12, cpu1=12
…after "module fault": I (527) housekeeping: reset_reason: cpu0=12, cpu1=12
…and no, the 12/12 were not sticky, I checked with a clean boot.
There's also a bug in the ESP32 that may trigger false positives: https://github.com/espressif/esp-idf/issues/494#issuecomment-291916959
I haven't had that effect up to now, but it seems we cannot rely on the reset reason.
Regards, Michael
Am 25.02.2018 um 15:06 schrieb Michael Balzer:
Am 22.02.2018 um 04:22 schrieb Mark Webb-Johnson:
When looking at the deep sleep stuff, I found there is a way to tag a global variable as ‘rtc’. That should survive a deep sleep (or reboot). Unfortunately, it does not survive a reboot:
* Data in RTC memory is initialised whenever the SoC restarts, except when waking from deep sleep. When waking from deep sleep, the values which were present before going to sleep are kept. There is an NVS library: https://esp-idf.readthedocs.io/en/v1.0/api/nvs_flash.html
…but I've got the impression that could interfere with our own flash usage (?).
Also, if flash is the way and as /store is already present at housekeeping init, I think we can just as well use our own config module…
Regards, Michael
-- 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
Mark, I also had the problem of losing auto start when rebooting within 10 seconds. I was about to add more config instances to track the state, but having the RTC RAM for this is much better. I wasn't aware of the option to add custom segments in there. I'll optimize the auto start logic after finishing the webserver fixes. Thanks, Michael Am 07.03.2018 um 15:39 schrieb Mark Webb-Johnson:
I’m having problems with this approach. Specifically, permanently disabling the auto start system if the system fails once during a boot.
I tried the module in my car today. Plugged it in, but the access point didn’t come up. No laptop, just an iPad.
It seems that while I was plugging it in, the power jiggled. So it booted for a second or so, reset, then booted again. It treated this as a problem, so turned off the auto init system permanently. No matter how many times I reset, I couldn’t get an access point to come up, and couldn’t get into the system from the iPad.
I’m not sure that storing this in config (fat filesystem) is optimal. I think the core reason for that was because the ESP IDF framework wipes RTC memory on boot for anything apart from a deep sleep. So, I set about finding a solution to that core problem. The result is quite neat, and visible in main/component.mk, and main/ovms_boot.*. It turns out that the ESP framework (start_cpu0) wipes the RTC BSS segment only. It leaves other RTC data untouched. So...
1. I create a linker section ‘.rtc.noload’. This goes in RTC slow ram, alongside the other RTC bss sections. But the NOLOAD flag is specified, to stop GCC from wiping this memory on boot.
2. I then create a typedef struct boot_data_t and storage boot_data to store the actual boot data. It is tagged __attribute__((section(".rtc.noload"))) to force it into that NOLOAD section. I’ve now got some data that never gets initialised, and survives a reset.
3. The last step is to check the actual boot reason (using rtc_get_reset_reason). If it is POWERON_RESET then I zero the boot_data storage (otherwise it is truly garbage - perhaps good for random number initialisation, but not much else).
It seems to work well for me, and is a quite neat solution. I added a ‘boot status’ command to show the status of the last boot, including the count of reboots.
Regarding differentiating between ‘module reset’ and another type of reset, I think we can now simply add a bool to boot_data_t and have ‘module reset’ set it before resetting. It can then be picked up during boot (reason SW_CPU_RESET, and check for this flag) to pickup on this specific case. If it is a SW_CPU_RESET and this flag is not set, then we can assume it was a crash.
With this, I think we can do some more sophisticated logic. The ‘first ten seconds’ flag goes in boot_data_t. We can also keep a count of failure resets during first 10 seconds, and if it exceeds say 5 then turn off auto init (but with a setting just in ram, leaving the config 'auto init' to indicate whether the user wants init to be auto or not).
Workable?
Regards, Mark.
On 26 Feb 2018, at 3:51 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
First version of the auto init system is in the hub.
As discussed, I added an "auto" config param. It currently has these instances:
Instance Default Remark ---------------------------------------------------------------------- init yes
wifi.mode ap off|ap|client wifi.ssid.ap OVMS wifi.ssid.client - empty = scanning mode
modem no
vehicle.type - moved from vehicle/type
server.v2 no server.v3 no
The web UI has a new config page for this as well.
On boot, the housekeeper temporarily sets "init" to false. 10 seconds after booting has finished it re-enables it, assuming the system is stable.
The auto wifi ap mode does a fallback to "OVMS" with the module password if no AP network is configured. It does not start the AP mode if the password is empty. So in order to enable the AP mode for configuration, it's sufficient to set the module password and leave all auto configs to their defaults.
Unfortunately a crash reboot seems to be indistinguishable from a manual reset. I've added a log output of the reset reason provided by the ESP. The reason codes are:
typedef enum { NO_MEAN = 0, POWERON_RESET = 1, /**<1, Vbat power on reset*/ SW_RESET = 3, /**<3, Software reset digital core*/ OWDT_RESET = 4, /**<4, Legacy watch dog reset digital core*/ DEEPSLEEP_RESET = 5, /**<3, Deep Sleep reset digital core*/ SDIO_RESET = 6, /**<6, Reset by SLC module, reset digital core*/ TG0WDT_SYS_RESET = 7, /**<7, Timer Group0 Watch dog reset digital core*/ TG1WDT_SYS_RESET = 8, /**<8, Timer Group1 Watch dog reset digital core*/ RTCWDT_SYS_RESET = 9, /**<9, RTC Watch dog Reset digital core*/ INTRUSION_RESET = 10, /**<10, Instrusion tested to reset CPU*/ TGWDT_CPU_RESET = 11, /**<11, Time Group reset CPU*/ SW_CPU_RESET = 12, /**<12, Software reset CPU*/ RTCWDT_CPU_RESET = 13, /**<13, RTC Watch dog Reset CPU*/ EXT_CPU_RESET = 14, /**<14, for APP CPU, reseted by PRO CPU*/ RTCWDT_BROWN_OUT_RESET = 15, /**<15, Reset when the vdd voltage is not stable*/ RTCWDT_RTC_RESET = 16 /**<16, RTC Watch dog reset digital core and rtc module*/ } RESET_REASON;
I get these values:
…boot after make app-flash: I (537) housekeeping: reset_reason: cpu0=1, cpu1=14
…after triggering vfs-edit-bug: I (527) housekeeping: reset_reason: cpu0=12, cpu1=12
…after "module reset": I (527) housekeeping: reset_reason: cpu0=12, cpu1=12
…after "module fault": I (527) housekeeping: reset_reason: cpu0=12, cpu1=12
…and no, the 12/12 were not sticky, I checked with a clean boot.
There's also a bug in the ESP32 that may trigger false positives: https://github.com/espressif/esp-idf/issues/494#issuecomment-291916959
I haven't had that effect up to now, but it seems we cannot rely on the reset reason.
Regards, Michael
Am 25.02.2018 um 15:06 schrieb Michael Balzer:
Am 22.02.2018 um 04:22 schrieb Mark Webb-Johnson:
When looking at the deep sleep stuff, I found there is a way to tag a global variable as ‘rtc’. That should survive a deep sleep (or reboot). Unfortunately, it does not survive a reboot:
* Data in RTC memory is initialised whenever the SoC restarts, except when waking from deep sleep. When waking from deep sleep, the values which were present before going to sleep are kept. There is an NVS library: https://esp-idf.readthedocs.io/en/v1.0/api/nvs_flash.html
…but I've got the impression that could interfere with our own flash usage (?).
Also, if flash is the way and as /store is already present at housekeeping init, I think we can just as well use our own config module…
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ 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
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
I wasn't aware of the option to add custom segments in there.
Me neither. It was fun finding out how to do this. I learned a lot about GCC linker scripts and how the Espressif IDF framework uses them. Also learned that the error messages coming out of the linker are so obscure as to be useless. I think we should be able to store the reason for a crash in that area, then after reboot submit it as a notification to the servers (in much the same way we did for OVMS v2, but more powerful as we have the reason before the crash, not just the crash itself). It seems that some of the system crash handlers can be overridden (such as void __attribute__((weak)) vApplicationStackOverflowHook).
I'll optimize the auto start logic after finishing the webserver fixes.
Thanks. Regards, Mark.
On 8 Mar 2018, at 1:25 AM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
I also had the problem of losing auto start when rebooting within 10 seconds. I was about to add more config instances to track the state, but having the RTC RAM for this is much better. I wasn't aware of the option to add custom segments in there.
I'll optimize the auto start logic after finishing the webserver fixes.
Thanks, Michael
Am 07.03.2018 um 15:39 schrieb Mark Webb-Johnson:
I’m having problems with this approach. Specifically, permanently disabling the auto start system if the system fails once during a boot.
I tried the module in my car today. Plugged it in, but the access point didn’t come up. No laptop, just an iPad.
It seems that while I was plugging it in, the power jiggled. So it booted for a second or so, reset, then booted again. It treated this as a problem, so turned off the auto init system permanently. No matter how many times I reset, I couldn’t get an access point to come up, and couldn’t get into the system from the iPad.
I’m not sure that storing this in config (fat filesystem) is optimal. I think the core reason for that was because the ESP IDF framework wipes RTC memory on boot for anything apart from a deep sleep. So, I set about finding a solution to that core problem. The result is quite neat, and visible in main/component.mk, and main/ovms_boot.*. It turns out that the ESP framework (start_cpu0) wipes the RTC BSS segment only. It leaves other RTC data untouched. So...
I create a linker section ‘.rtc.noload’. This goes in RTC slow ram, alongside the other RTC bss sections. But the NOLOAD flag is specified, to stop GCC from wiping this memory on boot.
I then create a typedef struct boot_data_t and storage boot_data to store the actual boot data. It is tagged __attribute__((section(".rtc.noload"))) to force it into that NOLOAD section. I’ve now got some data that never gets initialised, and survives a reset.
The last step is to check the actual boot reason (using rtc_get_reset_reason). If it is POWERON_RESET then I zero the boot_data storage (otherwise it is truly garbage - perhaps good for random number initialisation, but not much else).
It seems to work well for me, and is a quite neat solution. I added a ‘boot status’ command to show the status of the last boot, including the count of reboots.
Regarding differentiating between ‘module reset’ and another type of reset, I think we can now simply add a bool to boot_data_t and have ‘module reset’ set it before resetting. It can then be picked up during boot (reason SW_CPU_RESET, and check for this flag) to pickup on this specific case. If it is a SW_CPU_RESET and this flag is not set, then we can assume it was a crash.
With this, I think we can do some more sophisticated logic. The ‘first ten seconds’ flag goes in boot_data_t. We can also keep a count of failure resets during first 10 seconds, and if it exceeds say 5 then turn off auto init (but with a setting just in ram, leaving the config 'auto init' to indicate whether the user wants init to be auto or not).
Workable?
Regards, Mark.
On 26 Feb 2018, at 3:51 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
First version of the auto init system is in the hub.
As discussed, I added an "auto" config param. It currently has these instances:
Instance Default Remark ---------------------------------------------------------------------- init yes
wifi.mode ap off|ap|client wifi.ssid.ap OVMS wifi.ssid.client - empty = scanning mode
modem no
vehicle.type - moved from vehicle/type
server.v2 no server.v3 no
The web UI has a new config page for this as well.
On boot, the housekeeper temporarily sets "init" to false. 10 seconds after booting has finished it re-enables it, assuming the system is stable.
The auto wifi ap mode does a fallback to "OVMS" with the module password if no AP network is configured. It does not start the AP mode if the password is empty. So in order to enable the AP mode for configuration, it's sufficient to set the module password and leave all auto configs to their defaults.
Unfortunately a crash reboot seems to be indistinguishable from a manual reset. I've added a log output of the reset reason provided by the ESP. The reason codes are:
typedef enum { NO_MEAN = 0, POWERON_RESET = 1, /**<1, Vbat power on reset*/ SW_RESET = 3, /**<3, Software reset digital core*/ OWDT_RESET = 4, /**<4, Legacy watch dog reset digital core*/ DEEPSLEEP_RESET = 5, /**<3, Deep Sleep reset digital core*/ SDIO_RESET = 6, /**<6, Reset by SLC module, reset digital core*/ TG0WDT_SYS_RESET = 7, /**<7, Timer Group0 Watch dog reset digital core*/ TG1WDT_SYS_RESET = 8, /**<8, Timer Group1 Watch dog reset digital core*/ RTCWDT_SYS_RESET = 9, /**<9, RTC Watch dog Reset digital core*/ INTRUSION_RESET = 10, /**<10, Instrusion tested to reset CPU*/ TGWDT_CPU_RESET = 11, /**<11, Time Group reset CPU*/ SW_CPU_RESET = 12, /**<12, Software reset CPU*/ RTCWDT_CPU_RESET = 13, /**<13, RTC Watch dog Reset CPU*/ EXT_CPU_RESET = 14, /**<14, for APP CPU, reseted by PRO CPU*/ RTCWDT_BROWN_OUT_RESET = 15, /**<15, Reset when the vdd voltage is not stable*/ RTCWDT_RTC_RESET = 16 /**<16, RTC Watch dog reset digital core and rtc module*/ } RESET_REASON;
I get these values:
…boot after make app-flash: I (537) housekeeping: reset_reason: cpu0=1, cpu1=14
…after triggering vfs-edit-bug: I (527) housekeeping: reset_reason: cpu0=12, cpu1=12
…after "module reset": I (527) housekeeping: reset_reason: cpu0=12, cpu1=12
…after "module fault": I (527) housekeeping: reset_reason: cpu0=12, cpu1=12
…and no, the 12/12 were not sticky, I checked with a clean boot.
There's also a bug in the ESP32 that may trigger false positives: https://github.com/espressif/esp-idf/issues/494#issuecomment-291916959 <https://github.com/espressif/esp-idf/issues/494#issuecomment-291916959>
I haven't had that effect up to now, but it seems we cannot rely on the reset reason.
Regards, Michael
Am 25.02.2018 um 15:06 schrieb Michael Balzer:
Am 22.02.2018 um 04:22 schrieb Mark Webb-Johnson:
When looking at the deep sleep stuff, I found there is a way to tag a global variable as ‘rtc’. That should survive a deep sleep (or reboot). Unfortunately, it does not survive a reboot:
* Data in RTC memory is initialised whenever the SoC restarts, except when waking from deep sleep. When waking from deep sleep, the values which were present before going to sleep are kept. There is an NVS library: https://esp-idf.readthedocs.io/en/v1.0/api/nvs_flash.html <https://esp-idf.readthedocs.io/en/v1.0/api/nvs_flash.html>
…but I've got the impression that could interfere with our own flash usage (?).
Also, if flash is the way and as /store is already present at housekeeping init, I think we can just as well use our own config module…
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ 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>
-- 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
Done: E (1226) housekeeping: Auto init inhibited: too many early crashes (6) … OVMS > boot status Last boot was 71 second(s) ago This is reset #6 since last power cycle Detected boot reason: EarlyCrash Crash counters: 6 total, 6 early CPU#0 boot reason was 12 CPU#1 boot reason was 12 A manual reset by "module reset" is detected as a soft reboot and resets all counters like a hard reset. Hard resets (i.e. ^T^R in the monitor) look just like a normal power on. Regards, Michael Am 08.03.2018 um 04:55 schrieb Mark Webb-Johnson:
I wasn't aware of the option to add custom segments in there.
Me neither. It was fun finding out how to do this. I learned a lot about GCC linker scripts and how the Espressif IDF framework uses them. Also learned that the error messages coming out of the linker are so obscure as to be useless.
I think we should be able to store the reason for a crash in that area, then after reboot submit it as a notification to the servers (in much the same way we did for OVMS v2, but more powerful as we have the reason before the crash, not just the crash itself). It seems that some of the system crash handlers can be overridden (such as void __attribute__((weak)) vApplicationStackOverflowHook).
I'll optimize the auto start logic after finishing the webserver fixes.
Thanks.
Regards, Mark.
On 8 Mar 2018, at 1:25 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
I also had the problem of losing auto start when rebooting within 10 seconds. I was about to add more config instances to track the state, but having the RTC RAM for this is much better. I wasn't aware of the option to add custom segments in there.
I'll optimize the auto start logic after finishing the webserver fixes.
Thanks, Michael
Am 07.03.2018 um 15:39 schrieb Mark Webb-Johnson:
I’m having problems with this approach. Specifically, permanently disabling the auto start system if the system fails once during a boot.
I tried the module in my car today. Plugged it in, but the access point didn’t come up. No laptop, just an iPad.
It seems that while I was plugging it in, the power jiggled. So it booted for a second or so, reset, then booted again. It treated this as a problem, so turned off the auto init system permanently. No matter how many times I reset, I couldn’t get an access point to come up, and couldn’t get into the system from the iPad.
I’m not sure that storing this in config (fat filesystem) is optimal. I think the core reason for that was because the ESP IDF framework wipes RTC memory on boot for anything apart from a deep sleep. So, I set about finding a solution to that core problem. The result is quite neat, and visible in main/component.mk, and main/ovms_boot.*. It turns out that the ESP framework (start_cpu0) wipes the RTC BSS segment only. It leaves other RTC data untouched. So...
1. I create a linker section ‘.rtc.noload’. This goes in RTC slow ram, alongside the other RTC bss sections. But the NOLOAD flag is specified, to stop GCC from wiping this memory on boot.
2. I then create a typedef struct boot_data_t and storage boot_data to store the actual boot data. It is tagged __attribute__((section(".rtc.noload"))) to force it into that NOLOAD section. I’ve now got some data that never gets initialised, and survives a reset.
3. The last step is to check the actual boot reason (using rtc_get_reset_reason). If it is POWERON_RESET then I zero the boot_data storage (otherwise it is truly garbage - perhaps good for random number initialisation, but not much else).
It seems to work well for me, and is a quite neat solution. I added a ‘boot status’ command to show the status of the last boot, including the count of reboots.
Regarding differentiating between ‘module reset’ and another type of reset, I think we can now simply add a bool to boot_data_t and have ‘module reset’ set it before resetting. It can then be picked up during boot (reason SW_CPU_RESET, and check for this flag) to pickup on this specific case. If it is a SW_CPU_RESET and this flag is not set, then we can assume it was a crash.
With this, I think we can do some more sophisticated logic. The ‘first ten seconds’ flag goes in boot_data_t. We can also keep a count of failure resets during first 10 seconds, and if it exceeds say 5 then turn off auto init (but with a setting just in ram, leaving the config 'auto init' to indicate whether the user wants init to be auto or not).
Workable?
Regards, Mark.
On 26 Feb 2018, at 3:51 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
First version of the auto init system is in the hub.
As discussed, I added an "auto" config param. It currently has these instances:
Instance Default Remark ---------------------------------------------------------------------- init yes
wifi.mode ap off|ap|client wifi.ssid.ap OVMS wifi.ssid.client - empty = scanning mode
modem no
vehicle.type - moved from vehicle/type
server.v2 no server.v3 no
The web UI has a new config page for this as well.
On boot, the housekeeper temporarily sets "init" to false. 10 seconds after booting has finished it re-enables it, assuming the system is stable.
The auto wifi ap mode does a fallback to "OVMS" with the module password if no AP network is configured. It does not start the AP mode if the password is empty. So in order to enable the AP mode for configuration, it's sufficient to set the module password and leave all auto configs to their defaults.
Unfortunately a crash reboot seems to be indistinguishable from a manual reset. I've added a log output of the reset reason provided by the ESP. The reason codes are:
typedef enum { NO_MEAN = 0, POWERON_RESET = 1, /**<1, Vbat power on reset*/ SW_RESET = 3, /**<3, Software reset digital core*/ OWDT_RESET = 4, /**<4, Legacy watch dog reset digital core*/ DEEPSLEEP_RESET = 5, /**<3, Deep Sleep reset digital core*/ SDIO_RESET = 6, /**<6, Reset by SLC module, reset digital core*/ TG0WDT_SYS_RESET = 7, /**<7, Timer Group0 Watch dog reset digital core*/ TG1WDT_SYS_RESET = 8, /**<8, Timer Group1 Watch dog reset digital core*/ RTCWDT_SYS_RESET = 9, /**<9, RTC Watch dog Reset digital core*/ INTRUSION_RESET = 10, /**<10, Instrusion tested to reset CPU*/ TGWDT_CPU_RESET = 11, /**<11, Time Group reset CPU*/ SW_CPU_RESET = 12, /**<12, Software reset CPU*/ RTCWDT_CPU_RESET = 13, /**<13, RTC Watch dog Reset CPU*/ EXT_CPU_RESET = 14, /**<14, for APP CPU, reseted by PRO CPU*/ RTCWDT_BROWN_OUT_RESET = 15, /**<15, Reset when the vdd voltage is not stable*/ RTCWDT_RTC_RESET = 16 /**<16, RTC Watch dog reset digital core and rtc module*/ } RESET_REASON;
I get these values:
…boot after make app-flash: I (537) housekeeping: reset_reason: cpu0=1, cpu1=14
…after triggering vfs-edit-bug: I (527) housekeeping: reset_reason: cpu0=12, cpu1=12
…after "module reset": I (527) housekeeping: reset_reason: cpu0=12, cpu1=12
…after "module fault": I (527) housekeeping: reset_reason: cpu0=12, cpu1=12
…and no, the 12/12 were not sticky, I checked with a clean boot.
There's also a bug in the ESP32 that may trigger false positives: https://github.com/espressif/esp-idf/issues/494#issuecomment-291916959
I haven't had that effect up to now, but it seems we cannot rely on the reset reason.
Regards, Michael
Am 25.02.2018 um 15:06 schrieb Michael Balzer:
Am 22.02.2018 um 04:22 schrieb Mark Webb-Johnson:
When looking at the deep sleep stuff, I found there is a way to tag a global variable as ‘rtc’. That should survive a deep sleep (or reboot). Unfortunately, it does not survive a reboot:
* Data in RTC memory is initialised whenever the SoC restarts, except when waking from deep sleep. When waking from deep sleep, the values which were present before going to sleep are kept. There is an NVS library: https://esp-idf.readthedocs.io/en/v1.0/api/nvs_flash.html
…but I've got the impression that could interfere with our own flash usage (?).
Also, if flash is the way and as /store is already present at housekeeping init, I think we can just as well use our own config module…
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ 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
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ 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
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Looks good to me. Working well in simulations (module fault). Regards, Mark.
On 9 Mar 2018, at 6:54 AM, Michael Balzer <dexter@expeedo.de> wrote:
Done:
E (1226) housekeeping: Auto init inhibited: too many early crashes (6) … OVMS > boot status Last boot was 71 second(s) ago This is reset #6 since last power cycle Detected boot reason: EarlyCrash Crash counters: 6 total, 6 early CPU#0 boot reason was 12 CPU#1 boot reason was 12
A manual reset by "module reset" is detected as a soft reboot and resets all counters like a hard reset. Hard resets (i.e. ^T^R in the monitor) look just like a normal power on.
Regards, Michael
Am 08.03.2018 um 04:55 schrieb Mark Webb-Johnson:
I wasn't aware of the option to add custom segments in there.
Me neither. It was fun finding out how to do this. I learned a lot about GCC linker scripts and how the Espressif IDF framework uses them. Also learned that the error messages coming out of the linker are so obscure as to be useless.
I think we should be able to store the reason for a crash in that area, then after reboot submit it as a notification to the servers (in much the same way we did for OVMS v2, but more powerful as we have the reason before the crash, not just the crash itself). It seems that some of the system crash handlers can be overridden (such as void __attribute__((weak)) vApplicationStackOverflowHook).
I'll optimize the auto start logic after finishing the webserver fixes.
Thanks.
Regards, Mark.
On 8 Mar 2018, at 1:25 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
I also had the problem of losing auto start when rebooting within 10 seconds. I was about to add more config instances to track the state, but having the RTC RAM for this is much better. I wasn't aware of the option to add custom segments in there.
I'll optimize the auto start logic after finishing the webserver fixes.
Thanks, Michael
Am 07.03.2018 um 15:39 schrieb Mark Webb-Johnson:
I’m having problems with this approach. Specifically, permanently disabling the auto start system if the system fails once during a boot.
I tried the module in my car today. Plugged it in, but the access point didn’t come up. No laptop, just an iPad.
It seems that while I was plugging it in, the power jiggled. So it booted for a second or so, reset, then booted again. It treated this as a problem, so turned off the auto init system permanently. No matter how many times I reset, I couldn’t get an access point to come up, and couldn’t get into the system from the iPad.
I’m not sure that storing this in config (fat filesystem) is optimal. I think the core reason for that was because the ESP IDF framework wipes RTC memory on boot for anything apart from a deep sleep. So, I set about finding a solution to that core problem. The result is quite neat, and visible in main/component.mk, and main/ovms_boot.*. It turns out that the ESP framework (start_cpu0) wipes the RTC BSS segment only. It leaves other RTC data untouched. So...
I create a linker section ‘.rtc.noload’. This goes in RTC slow ram, alongside the other RTC bss sections. But the NOLOAD flag is specified, to stop GCC from wiping this memory on boot.
I then create a typedef struct boot_data_t and storage boot_data to store the actual boot data. It is tagged __attribute__((section(".rtc.noload"))) to force it into that NOLOAD section. I’ve now got some data that never gets initialised, and survives a reset.
The last step is to check the actual boot reason (using rtc_get_reset_reason). If it is POWERON_RESET then I zero the boot_data storage (otherwise it is truly garbage - perhaps good for random number initialisation, but not much else).
It seems to work well for me, and is a quite neat solution. I added a ‘boot status’ command to show the status of the last boot, including the count of reboots.
Regarding differentiating between ‘module reset’ and another type of reset, I think we can now simply add a bool to boot_data_t and have ‘module reset’ set it before resetting. It can then be picked up during boot (reason SW_CPU_RESET, and check for this flag) to pickup on this specific case. If it is a SW_CPU_RESET and this flag is not set, then we can assume it was a crash.
With this, I think we can do some more sophisticated logic. The ‘first ten seconds’ flag goes in boot_data_t. We can also keep a count of failure resets during first 10 seconds, and if it exceeds say 5 then turn off auto init (but with a setting just in ram, leaving the config 'auto init' to indicate whether the user wants init to be auto or not).
Workable?
Regards, Mark.
On 26 Feb 2018, at 3:51 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
First version of the auto init system is in the hub.
As discussed, I added an "auto" config param. It currently has these instances:
Instance Default Remark ---------------------------------------------------------------------- init yes
wifi.mode ap off|ap|client wifi.ssid.ap OVMS wifi.ssid.client - empty = scanning mode
modem no
vehicle.type - moved from vehicle/type
server.v2 no server.v3 no
The web UI has a new config page for this as well.
On boot, the housekeeper temporarily sets "init" to false. 10 seconds after booting has finished it re-enables it, assuming the system is stable.
The auto wifi ap mode does a fallback to "OVMS" with the module password if no AP network is configured. It does not start the AP mode if the password is empty. So in order to enable the AP mode for configuration, it's sufficient to set the module password and leave all auto configs to their defaults.
Unfortunately a crash reboot seems to be indistinguishable from a manual reset. I've added a log output of the reset reason provided by the ESP. The reason codes are:
typedef enum { NO_MEAN = 0, POWERON_RESET = 1, /**<1, Vbat power on reset*/ SW_RESET = 3, /**<3, Software reset digital core*/ OWDT_RESET = 4, /**<4, Legacy watch dog reset digital core*/ DEEPSLEEP_RESET = 5, /**<3, Deep Sleep reset digital core*/ SDIO_RESET = 6, /**<6, Reset by SLC module, reset digital core*/ TG0WDT_SYS_RESET = 7, /**<7, Timer Group0 Watch dog reset digital core*/ TG1WDT_SYS_RESET = 8, /**<8, Timer Group1 Watch dog reset digital core*/ RTCWDT_SYS_RESET = 9, /**<9, RTC Watch dog Reset digital core*/ INTRUSION_RESET = 10, /**<10, Instrusion tested to reset CPU*/ TGWDT_CPU_RESET = 11, /**<11, Time Group reset CPU*/ SW_CPU_RESET = 12, /**<12, Software reset CPU*/ RTCWDT_CPU_RESET = 13, /**<13, RTC Watch dog Reset CPU*/ EXT_CPU_RESET = 14, /**<14, for APP CPU, reseted by PRO CPU*/ RTCWDT_BROWN_OUT_RESET = 15, /**<15, Reset when the vdd voltage is not stable*/ RTCWDT_RTC_RESET = 16 /**<16, RTC Watch dog reset digital core and rtc module*/ } RESET_REASON;
I get these values:
…boot after make app-flash: I (537) housekeeping: reset_reason: cpu0=1, cpu1=14
…after triggering vfs-edit-bug: I (527) housekeeping: reset_reason: cpu0=12, cpu1=12
…after "module reset": I (527) housekeeping: reset_reason: cpu0=12, cpu1=12
…after "module fault": I (527) housekeeping: reset_reason: cpu0=12, cpu1=12
…and no, the 12/12 were not sticky, I checked with a clean boot.
There's also a bug in the ESP32 that may trigger false positives: https://github.com/espressif/esp-idf/issues/494#issuecomment-291916959 <https://github.com/espressif/esp-idf/issues/494#issuecomment-291916959>
I haven't had that effect up to now, but it seems we cannot rely on the reset reason.
Regards, Michael
Am 25.02.2018 um 15:06 schrieb Michael Balzer:
Am 22.02.2018 um 04:22 schrieb Mark Webb-Johnson: > When looking at the deep sleep stuff, I found there is a way to tag a global variable as ‘rtc’. That should survive a deep sleep (or reboot). Unfortunately, it does not survive a reboot:
> * Data in RTC memory is initialised whenever the SoC restarts, except when waking from deep sleep. When waking from deep sleep, the values which were present > before going to sleep are kept. There is an NVS library: https://esp-idf.readthedocs.io/en/v1.0/api/nvs_flash.html <https://esp-idf.readthedocs.io/en/v1.0/api/nvs_flash.html>
…but I've got the impression that could interfere with our own flash usage (?).
Also, if flash is the way and as /store is already present at housekeeping init, I think we can just as well use our own config module…
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ 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>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ 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>
-- 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
Should we extend that logic to also cover firmware updates? I.e. if the system can't get to the stable state after disabling auto init, we could try to activate the other ota partition with a fallback to factory. Regards, Michael Am 09.03.2018 um 07:14 schrieb Mark Webb-Johnson:
Looks good to me. Working well in simulations (module fault).
Regards, Mark.
On 9 Mar 2018, at 6:54 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Done:
E (1226) housekeeping: Auto init inhibited: too many early crashes (6) … OVMS > boot status Last boot was 71 second(s) ago This is reset #6 since last power cycle Detected boot reason: EarlyCrash Crash counters: 6 total, 6 early CPU#0 boot reason was 12 CPU#1 boot reason was 12
A manual reset by "module reset" is detected as a soft reboot and resets all counters like a hard reset. Hard resets (i.e. ^T^R in the monitor) look just like a normal power on.
Regards, Michael
Am 08.03.2018 um 04:55 schrieb Mark Webb-Johnson:
I wasn't aware of the option to add custom segments in there.
Me neither. It was fun finding out how to do this. I learned a lot about GCC linker scripts and how the Espressif IDF framework uses them. Also learned that the error messages coming out of the linker are so obscure as to be useless.
I think we should be able to store the reason for a crash in that area, then after reboot submit it as a notification to the servers (in much the same way we did for OVMS v2, but more powerful as we have the reason before the crash, not just the crash itself). It seems that some of the system crash handlers can be overridden (such as void __attribute__((weak)) vApplicationStackOverflowHook).
I'll optimize the auto start logic after finishing the webserver fixes.
Thanks.
Regards, Mark.
On 8 Mar 2018, at 1:25 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
I also had the problem of losing auto start when rebooting within 10 seconds. I was about to add more config instances to track the state, but having the RTC RAM for this is much better. I wasn't aware of the option to add custom segments in there.
I'll optimize the auto start logic after finishing the webserver fixes.
Thanks, Michael
Am 07.03.2018 um 15:39 schrieb Mark Webb-Johnson:
I’m having problems with this approach. Specifically, permanently disabling the auto start system if the system fails once during a boot.
I tried the module in my car today. Plugged it in, but the access point didn’t come up. No laptop, just an iPad.
It seems that while I was plugging it in, the power jiggled. So it booted for a second or so, reset, then booted again. It treated this as a problem, so turned off the auto init system permanently. No matter how many times I reset, I couldn’t get an access point to come up, and couldn’t get into the system from the iPad.
I’m not sure that storing this in config (fat filesystem) is optimal. I think the core reason for that was because the ESP IDF framework wipes RTC memory on boot for anything apart from a deep sleep. So, I set about finding a solution to that core problem. The result is quite neat, and visible in main/component.mk, and main/ovms_boot.*. It turns out that the ESP framework (start_cpu0) wipes the RTC BSS segment only. It leaves other RTC data untouched. So...
1. I create a linker section ‘.rtc.noload’. This goes in RTC slow ram, alongside the other RTC bss sections. But the NOLOAD flag is specified, to stop GCC from wiping this memory on boot.
2. I then create a typedef struct boot_data_t and storage boot_data to store the actual boot data. It is tagged __attribute__((section(".rtc.noload"))) to force it into that NOLOAD section. I’ve now got some data that never gets initialised, and survives a reset.
3. The last step is to check the actual boot reason (using rtc_get_reset_reason). If it is POWERON_RESET then I zero the boot_data storage (otherwise it is truly garbage - perhaps good for random number initialisation, but not much else).
It seems to work well for me, and is a quite neat solution. I added a ‘boot status’ command to show the status of the last boot, including the count of reboots.
Regarding differentiating between ‘module reset’ and another type of reset, I think we can now simply add a bool to boot_data_t and have ‘module reset’ set it before resetting. It can then be picked up during boot (reason SW_CPU_RESET, and check for this flag) to pickup on this specific case. If it is a SW_CPU_RESET and this flag is not set, then we can assume it was a crash.
With this, I think we can do some more sophisticated logic. The ‘first ten seconds’ flag goes in boot_data_t. We can also keep a count of failure resets during first 10 seconds, and if it exceeds say 5 then turn off auto init (but with a setting just in ram, leaving the config 'auto init' to indicate whether the user wants init to be auto or not).
Workable?
Regards, Mark.
On 26 Feb 2018, at 3:51 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
First version of the auto init system is in the hub.
As discussed, I added an "auto" config param. It currently has these instances:
Instance Default Remark ---------------------------------------------------------------------- init yes
wifi.mode ap off|ap|client wifi.ssid.ap OVMS wifi.ssid.client - empty = scanning mode
modem no
vehicle.type - moved from vehicle/type
server.v2 no server.v3 no
The web UI has a new config page for this as well.
On boot, the housekeeper temporarily sets "init" to false. 10 seconds after booting has finished it re-enables it, assuming the system is stable.
The auto wifi ap mode does a fallback to "OVMS" with the module password if no AP network is configured. It does not start the AP mode if the password is empty. So in order to enable the AP mode for configuration, it's sufficient to set the module password and leave all auto configs to their defaults.
Unfortunately a crash reboot seems to be indistinguishable from a manual reset. I've added a log output of the reset reason provided by the ESP. The reason codes are:
typedef enum { NO_MEAN = 0, POWERON_RESET = 1, /**<1, Vbat power on reset*/ SW_RESET = 3, /**<3, Software reset digital core*/ OWDT_RESET = 4, /**<4, Legacy watch dog reset digital core*/ DEEPSLEEP_RESET = 5, /**<3, Deep Sleep reset digital core*/ SDIO_RESET = 6, /**<6, Reset by SLC module, reset digital core*/ TG0WDT_SYS_RESET = 7, /**<7, Timer Group0 Watch dog reset digital core*/ TG1WDT_SYS_RESET = 8, /**<8, Timer Group1 Watch dog reset digital core*/ RTCWDT_SYS_RESET = 9, /**<9, RTC Watch dog Reset digital core*/ INTRUSION_RESET = 10, /**<10, Instrusion tested to reset CPU*/ TGWDT_CPU_RESET = 11, /**<11, Time Group reset CPU*/ SW_CPU_RESET = 12, /**<12, Software reset CPU*/ RTCWDT_CPU_RESET = 13, /**<13, RTC Watch dog Reset CPU*/ EXT_CPU_RESET = 14, /**<14, for APP CPU, reseted by PRO CPU*/ RTCWDT_BROWN_OUT_RESET = 15, /**<15, Reset when the vdd voltage is not stable*/ RTCWDT_RTC_RESET = 16 /**<16, RTC Watch dog reset digital core and rtc module*/ } RESET_REASON;
I get these values:
…boot after make app-flash: I (537) housekeeping: reset_reason: cpu0=1, cpu1=14
…after triggering vfs-edit-bug: I (527) housekeeping: reset_reason: cpu0=12, cpu1=12
…after "module reset": I (527) housekeeping: reset_reason: cpu0=12, cpu1=12
…after "module fault": I (527) housekeeping: reset_reason: cpu0=12, cpu1=12
…and no, the 12/12 were not sticky, I checked with a clean boot.
There's also a bug in the ESP32 that may trigger false positives: https://github.com/espressif/esp-idf/issues/494#issuecomment-291916959
I haven't had that effect up to now, but it seems we cannot rely on the reset reason.
Regards, Michael
Am 25.02.2018 um 15:06 schrieb Michael Balzer: > Am 22.02.2018 um 04:22 schrieb Mark Webb-Johnson: >> When looking at the deep sleep stuff, I found there is a way to tag a global variable as ‘rtc’. That should survive a deep sleep (or reboot). > Unfortunately, it does not survive a reboot: > >> * Data in RTC memory is initialised whenever the SoC restarts, except when waking from deep sleep. When waking from deep sleep, the values which were >> present >> before going to sleep are kept. > There is an NVS library: https://esp-idf.readthedocs.io/en/v1.0/api/nvs_flash.html > > …but I've got the impression that could interfere with our own flash usage (?). > > Also, if flash is the way and as /store is already present at housekeeping init, I think we can just as well use our own config module… > > Regards, > Michael >
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ 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
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ 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
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ 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
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
I guess it is possible, but probably easiest to just fallback to factory (rather than the other OTA partition). I suggest something like if auto is inhibited, and we’ve had five further crashes within 10 seconds of boot, and we are running OTA, then switch back to factory. Regards, Mark
On 9 Mar 2018, at 11:29 PM, Michael Balzer <dexter@expeedo.de> wrote:
Should we extend that logic to also cover firmware updates?
I.e. if the system can't get to the stable state after disabling auto init, we could try to activate the other ota partition with a fallback to factory.
Regards, Michael
Am 09.03.2018 um 07:14 schrieb Mark Webb-Johnson:
Looks good to me. Working well in simulations (module fault).
Regards, Mark.
On 9 Mar 2018, at 6:54 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Done:
E (1226) housekeeping: Auto init inhibited: too many early crashes (6) … OVMS > boot status Last boot was 71 second(s) ago This is reset #6 since last power cycle Detected boot reason: EarlyCrash Crash counters: 6 total, 6 early CPU#0 boot reason was 12 CPU#1 boot reason was 12
A manual reset by "module reset" is detected as a soft reboot and resets all counters like a hard reset. Hard resets (i.e. ^T^R in the monitor) look just like a normal power on.
Regards, Michael
Am 08.03.2018 um 04:55 schrieb Mark Webb-Johnson:
I wasn't aware of the option to add custom segments in there.
Me neither. It was fun finding out how to do this. I learned a lot about GCC linker scripts and how the Espressif IDF framework uses them. Also learned that the error messages coming out of the linker are so obscure as to be useless.
I think we should be able to store the reason for a crash in that area, then after reboot submit it as a notification to the servers (in much the same way we did for OVMS v2, but more powerful as we have the reason before the crash, not just the crash itself). It seems that some of the system crash handlers can be overridden (such as void __attribute__((weak)) vApplicationStackOverflowHook).
I'll optimize the auto start logic after finishing the webserver fixes.
Thanks.
Regards, Mark.
On 8 Mar 2018, at 1:25 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
I also had the problem of losing auto start when rebooting within 10 seconds. I was about to add more config instances to track the state, but having the RTC RAM for this is much better. I wasn't aware of the option to add custom segments in there.
I'll optimize the auto start logic after finishing the webserver fixes.
Thanks, Michael
Am 07.03.2018 um 15:39 schrieb Mark Webb-Johnson:
I’m having problems with this approach. Specifically, permanently disabling the auto start system if the system fails once during a boot.
I tried the module in my car today. Plugged it in, but the access point didn’t come up. No laptop, just an iPad.
It seems that while I was plugging it in, the power jiggled. So it booted for a second or so, reset, then booted again. It treated this as a problem, so turned off the auto init system permanently. No matter how many times I reset, I couldn’t get an access point to come up, and couldn’t get into the system from the iPad.
I’m not sure that storing this in config (fat filesystem) is optimal. I think the core reason for that was because the ESP IDF framework wipes RTC memory on boot for anything apart from a deep sleep. So, I set about finding a solution to that core problem. The result is quite neat, and visible in main/component.mk, and main/ovms_boot.*. It turns out that the ESP framework (start_cpu0) wipes the RTC BSS segment only. It leaves other RTC data untouched. So...
I create a linker section ‘.rtc.noload’. This goes in RTC slow ram, alongside the other RTC bss sections. But the NOLOAD flag is specified, to stop GCC from wiping this memory on boot.
I then create a typedef struct boot_data_t and storage boot_data to store the actual boot data. It is tagged __attribute__((section(".rtc.noload"))) to force it into that NOLOAD section. I’ve now got some data that never gets initialised, and survives a reset.
The last step is to check the actual boot reason (using rtc_get_reset_reason). If it is POWERON_RESET then I zero the boot_data storage (otherwise it is truly garbage - perhaps good for random number initialisation, but not much else).
It seems to work well for me, and is a quite neat solution. I added a ‘boot status’ command to show the status of the last boot, including the count of reboots.
Regarding differentiating between ‘module reset’ and another type of reset, I think we can now simply add a bool to boot_data_t and have ‘module reset’ set it before resetting. It can then be picked up during boot (reason SW_CPU_RESET, and check for this flag) to pickup on this specific case. If it is a SW_CPU_RESET and this flag is not set, then we can assume it was a crash.
With this, I think we can do some more sophisticated logic. The ‘first ten seconds’ flag goes in boot_data_t. We can also keep a count of failure resets during first 10 seconds, and if it exceeds say 5 then turn off auto init (but with a setting just in ram, leaving the config 'auto init' to indicate whether the user wants init to be auto or not).
Workable?
Regards, Mark.
> On 26 Feb 2018, at 3:51 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: > > First version of the auto init system is in the hub. > > As discussed, I added an "auto" config param. It currently has these instances: > > Instance Default Remark > ---------------------------------------------------------------------- > init yes > > wifi.mode ap off|ap|client > wifi.ssid.ap OVMS > wifi.ssid.client - empty = scanning mode > > modem no > > vehicle.type - moved from vehicle/type > > server.v2 no > server.v3 no > > > The web UI has a new config page for this as well. > > On boot, the housekeeper temporarily sets "init" to false. 10 seconds after booting has finished it re-enables it, assuming the system is stable. > > The auto wifi ap mode does a fallback to "OVMS" with the module password if no AP network is configured. It does not start the AP mode if the password is empty. > So in order to enable the AP mode for configuration, it's sufficient to set the module password and leave all auto configs to their defaults. > > > Unfortunately a crash reboot seems to be indistinguishable from a manual reset. I've added a log output of the reset reason provided by the ESP. The reason > codes are: > > typedef enum { > NO_MEAN = 0, > POWERON_RESET = 1, /**<1, Vbat power on reset*/ > SW_RESET = 3, /**<3, Software reset digital core*/ > OWDT_RESET = 4, /**<4, Legacy watch dog reset digital core*/ > DEEPSLEEP_RESET = 5, /**<3, Deep Sleep reset digital core*/ > SDIO_RESET = 6, /**<6, Reset by SLC module, reset digital core*/ > TG0WDT_SYS_RESET = 7, /**<7, Timer Group0 Watch dog reset digital core*/ > TG1WDT_SYS_RESET = 8, /**<8, Timer Group1 Watch dog reset digital core*/ > RTCWDT_SYS_RESET = 9, /**<9, RTC Watch dog Reset digital core*/ > INTRUSION_RESET = 10, /**<10, Instrusion tested to reset CPU*/ > TGWDT_CPU_RESET = 11, /**<11, Time Group reset CPU*/ > SW_CPU_RESET = 12, /**<12, Software reset CPU*/ > RTCWDT_CPU_RESET = 13, /**<13, RTC Watch dog Reset CPU*/ > EXT_CPU_RESET = 14, /**<14, for APP CPU, reseted by PRO CPU*/ > RTCWDT_BROWN_OUT_RESET = 15, /**<15, Reset when the vdd voltage is not stable*/ > RTCWDT_RTC_RESET = 16 /**<16, RTC Watch dog reset digital core and rtc module*/ > } RESET_REASON; > > I get these values: > > …boot after make app-flash: > I (537) housekeeping: reset_reason: cpu0=1, cpu1=14 > > …after triggering vfs-edit-bug: > I (527) housekeeping: reset_reason: cpu0=12, cpu1=12 > > …after "module reset": > I (527) housekeeping: reset_reason: cpu0=12, cpu1=12 > > …after "module fault": > I (527) housekeeping: reset_reason: cpu0=12, cpu1=12 > > …and no, the 12/12 were not sticky, I checked with a clean boot. > > There's also a bug in the ESP32 that may trigger false positives: https://github.com/espressif/esp-idf/issues/494#issuecomment-291916959 <https://github.com/espressif/esp-idf/issues/494#issuecomment-291916959> > > I haven't had that effect up to now, but it seems we cannot rely on the reset reason. > > Regards, > Michael > > > Am 25.02.2018 um 15:06 schrieb Michael Balzer: >> Am 22.02.2018 um 04:22 schrieb Mark Webb-Johnson: >>> When looking at the deep sleep stuff, I found there is a way to tag a global variable as ‘rtc’. That should survive a deep sleep (or reboot). >> Unfortunately, it does not survive a reboot: >> >>> * Data in RTC memory is initialised whenever the SoC restarts, except when waking from deep sleep. When waking from deep sleep, the values which were present >>> before going to sleep are kept. >> There is an NVS library: https://esp-idf.readthedocs.io/en/v1.0/api/nvs_flash.html <https://esp-idf.readthedocs.io/en/v1.0/api/nvs_flash.html> >> >> …but I've got the impression that could interfere with our own flash usage (?). >> >> Also, if flash is the way and as /store is already present at housekeeping init, I think we can just as well use our own config module… >> >> Regards, >> Michael >> > > -- > Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal > Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 > > _______________________________________________ > 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>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ 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>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ 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>
-- 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
Just curious... What version is "factory" on the units being built now?
I haven’t given them it yet. They’ll ask for it perhaps end of this week, or early next, and then I’ll have to provide whatever we have ready then. Regards, Mark.
On 12 Mar 2018, at 1:27 AM, Greg D. <gregd2350@gmail.com> wrote:
Falling back to the prior version (other OTA partition) is more traditional, but once things get settled, we probably won't need the added complexity. The factory version should support enough automation that recovery would be easy.
Just curious... What version is "factory" on the units being built now?
Greg
Mark Webb-Johnson wrote:
I guess it is possible, but probably easiest to just fallback to factory (rather than the other OTA partition).
I suggest something like if auto is inhibited, and we’ve had five further crashes within 10 seconds of boot, and we are running OTA, then switch back to factory.
Regards, Mark
On 9 Mar 2018, at 11:29 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Should we extend that logic to also cover firmware updates?
I.e. if the system can't get to the stable state after disabling auto init, we could try to activate the other ota partition with a fallback to factory.
Regards, Michael
Am 09.03.2018 um 07:14 schrieb Mark Webb-Johnson:
Looks good to me. Working well in simulations (module fault).
Regards, Mark.
On 9 Mar 2018, at 6:54 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Done:
E (1226) housekeeping: Auto init inhibited: too many early crashes (6) … OVMS > boot status Last boot was 71 second(s) ago This is reset #6 since last power cycle Detected boot reason: EarlyCrash Crash counters: 6 total, 6 early CPU#0 boot reason was 12 CPU#1 boot reason was 12
A manual reset by "module reset" is detected as a soft reboot and resets all counters like a hard reset. Hard resets (i.e. ^T^R in the monitor) look just like a normal power on.
Regards, Michael
Am 08.03.2018 um 04:55 schrieb Mark Webb-Johnson:
> I wasn't aware of the option to add custom segments in there.
Me neither. It was fun finding out how to do this. I learned a lot about GCC linker scripts and how the Espressif IDF framework uses them. Also learned that the error messages coming out of the linker are so obscure as to be useless.
I think we should be able to store the reason for a crash in that area, then after reboot submit it as a notification to the servers (in much the same way we did for OVMS v2, but more powerful as we have the reason before the crash, not just the crash itself). It seems that some of the system crash handlers can be overridden (such as void __attribute__((weak)) vApplicationStackOverflowHook).
> I'll optimize the auto start logic after finishing the webserver fixes.
Thanks.
Regards, Mark.
> On 8 Mar 2018, at 1:25 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: > > Mark, > > I also had the problem of losing auto start when rebooting within 10 seconds. I was about to add more config instances to track the state, but having the RTC RAM for this is much better. I wasn't aware of the option to add custom segments in there. > > I'll optimize the auto start logic after finishing the webserver fixes. > > Thanks, > Michael > > > Am 07.03.2018 um 15:39 schrieb Mark Webb-Johnson: >> I’m having problems with this approach. Specifically, permanently disabling the auto start system if the system fails once during a boot. >> >> I tried the module in my car today. Plugged it in, but the access point didn’t come up. No laptop, just an iPad. >> >> It seems that while I was plugging it in, the power jiggled. So it booted for a second or so, reset, then booted again. It treated this as a problem, so turned off the auto init system permanently. No matter how many times I reset, I couldn’t get an access point to come up, and couldn’t get into the system from the iPad. >> >> I’m not sure that storing this in config (fat filesystem) is optimal. I think the core reason for that was because the ESP IDF framework wipes RTC memory on boot for anything apart from a deep sleep. So, I set about finding a solution to that core problem. The result is quite neat, and visible in main/component.mk, and main/ovms_boot.*. It turns out that the ESP framework (start_cpu0) wipes the RTC BSS segment only. It leaves other RTC data untouched. So... >> >> I create a linker section ‘.rtc.noload’. This goes in RTC slow ram, alongside the other RTC bss sections. But the NOLOAD flag is specified, to stop GCC from wiping this memory on boot. >> >> I then create a typedef struct boot_data_t and storage boot_data to store the actual boot data. It is tagged __attribute__((section(".rtc.noload"))) to force it into that NOLOAD section. I’ve now got some data that never gets initialised, and survives a reset. >> >> The last step is to check the actual boot reason (using rtc_get_reset_reason). If it is POWERON_RESET then I zero the boot_data storage (otherwise it is truly garbage - perhaps good for random number initialisation, but not much else). >> >> It seems to work well for me, and is a quite neat solution. I added a ‘boot status’ command to show the status of the last boot, including the count of reboots. >> >> Regarding differentiating between ‘module reset’ and another type of reset, I think we can now simply add a bool to boot_data_t and have ‘module reset’ set it before resetting. It can then be picked up during boot (reason SW_CPU_RESET, and check for this flag) to pickup on this specific case. If it is a SW_CPU_RESET and this flag is not set, then we can assume it was a crash. >> >> With this, I think we can do some more sophisticated logic. The ‘first ten seconds’ flag goes in boot_data_t. We can also keep a count of failure resets during first 10 seconds, and if it exceeds say 5 then turn off auto init (but with a setting just in ram, leaving the config 'auto init' to indicate whether the user wants init to be auto or not). >> >> Workable? >> >> Regards, Mark. >> >>> On 26 Feb 2018, at 3:51 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: >>> >>> First version of the auto init system is in the hub. >>> >>> As discussed, I added an "auto" config param. It currently has these instances: >>> >>> Instance Default Remark >>> ---------------------------------------------------------------------- >>> init yes >>> >>> wifi.mode ap off|ap|client >>> wifi.ssid.ap OVMS >>> wifi.ssid.client - empty = scanning mode >>> >>> modem no >>> >>> vehicle.type - moved from vehicle/type >>> >>> server.v2 no >>> server.v3 no >>> >>> >>> The web UI has a new config page for this as well. >>> >>> On boot, the housekeeper temporarily sets "init" to false. 10 seconds after booting has finished it re-enables it, assuming the system is stable. >>> >>> The auto wifi ap mode does a fallback to "OVMS" with the module password if no AP network is configured. It does not start the AP mode if the password is empty. >>> So in order to enable the AP mode for configuration, it's sufficient to set the module password and leave all auto configs to their defaults. >>> >>> >>> Unfortunately a crash reboot seems to be indistinguishable from a manual reset. I've added a log output of the reset reason provided by the ESP. The reason >>> codes are: >>> >>> typedef enum { >>> NO_MEAN = 0, >>> POWERON_RESET = 1, /**<1, Vbat power on reset*/ >>> SW_RESET = 3, /**<3, Software reset digital core*/ >>> OWDT_RESET = 4, /**<4, Legacy watch dog reset digital core*/ >>> DEEPSLEEP_RESET = 5, /**<3, Deep Sleep reset digital core*/ >>> SDIO_RESET = 6, /**<6, Reset by SLC module, reset digital core*/ >>> TG0WDT_SYS_RESET = 7, /**<7, Timer Group0 Watch dog reset digital core*/ >>> TG1WDT_SYS_RESET = 8, /**<8, Timer Group1 Watch dog reset digital core*/ >>> RTCWDT_SYS_RESET = 9, /**<9, RTC Watch dog Reset digital core*/ >>> INTRUSION_RESET = 10, /**<10, Instrusion tested to reset CPU*/ >>> TGWDT_CPU_RESET = 11, /**<11, Time Group reset CPU*/ >>> SW_CPU_RESET = 12, /**<12, Software reset CPU*/ >>> RTCWDT_CPU_RESET = 13, /**<13, RTC Watch dog Reset CPU*/ >>> EXT_CPU_RESET = 14, /**<14, for APP CPU, reseted by PRO CPU*/ >>> RTCWDT_BROWN_OUT_RESET = 15, /**<15, Reset when the vdd voltage is not stable*/ >>> RTCWDT_RTC_RESET = 16 /**<16, RTC Watch dog reset digital core and rtc module*/ >>> } RESET_REASON; >>> >>> I get these values: >>> >>> …boot after make app-flash: >>> I (537) housekeeping: reset_reason: cpu0=1, cpu1=14 >>> >>> …after triggering vfs-edit-bug: >>> I (527) housekeeping: reset_reason: cpu0=12, cpu1=12 >>> >>> …after "module reset": >>> I (527) housekeeping: reset_reason: cpu0=12, cpu1=12 >>> >>> …after "module fault": >>> I (527) housekeeping: reset_reason: cpu0=12, cpu1=12 >>> >>> …and no, the 12/12 were not sticky, I checked with a clean boot. >>> >>> There's also a bug in the ESP32 that may trigger false positives: https://github.com/espressif/esp-idf/issues/494#issuecomment-291916959 <https://github.com/espressif/esp-idf/issues/494#issuecomment-291916959> >>> >>> I haven't had that effect up to now, but it seems we cannot rely on the reset reason. >>> >>> Regards, >>> Michael >>> >>> >>> Am 25.02.2018 um 15:06 schrieb Michael Balzer: >>>> Am 22.02.2018 um 04:22 schrieb Mark Webb-Johnson: >>>>> When looking at the deep sleep stuff, I found there is a way to tag a global variable as ‘rtc’. That should survive a deep sleep (or reboot). >>>> Unfortunately, it does not survive a reboot: >>>> >>>>> * Data in RTC memory is initialised whenever the SoC restarts, except when waking from deep sleep. When waking from deep sleep, the values which were present >>>>> before going to sleep are kept. >>>> There is an NVS library: https://esp-idf.readthedocs.io/en/v1.0/api/nvs_flash.html <https://esp-idf.readthedocs.io/en/v1.0/api/nvs_flash.html> >>>> >>>> …but I've got the impression that could interfere with our own flash usage (?). >>>> >>>> Also, if flash is the way and as /store is already present at housekeeping init, I think we can just as well use our own config module… >>>> >>>> Regards, >>>> Michael >>>> >>> >>> -- >>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal >>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 >>> >>> _______________________________________________ >>> 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> > > -- > Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal > Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 > _______________________________________________ > 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>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ 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>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ 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
participants (6)
-
Charles Cangialose -
Greg D. -
Mark Webb-Johnson -
Michael Balzer -
Stephen Casner -
Tom Parker