I’ve released what I have so far at: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3> From now on, I’ll push directly to there, and accept pull requests. DEVKIT-C To get it up and running on a DEVKIT-C style device, you will have to ‘make menuconfig’, and change (a) flash size to 1MB, (b) partition table to just a single factory image (no OTA). That will break when we bring the config system and SPIFS filesystem in flash online, but is workable for the moment. Our OTA and config flash will just rely on the partition table contents, so should continue to work with this (although you will need a custom partition table to work in 4MB). A better solution is to use an external 16MB flash chip, on a breadboard with the DEVKIT-C. Not hard to do. Physical wiring (for W25R128 and DEVKIT-C): #1 -> IO22 (FL_CS2) #2 -> SD0 (FL_SD0) #3 -> SD3 (FL_WP) #4 -> GND #5 -> SD1 (FL_SD1) #6 -> CLK (FL_CLK) #7 -> SD2 (FL_HOLD) #8 -> 3.3v Fuse blowing (take great care - this is a one-time operation): espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse XPD_SDIO_REG 1 espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse XPD_SDIO_TIEH 1 espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse XPD_SDIO_FORCE 1 espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse SPI_PAD_CONFIG_CLK 6 espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse SPI_PAD_CONFIG_Q 7 espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse SPI_PAD_CONFIG_D 8 espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse SPI_PAD_CONFIG_HD 9 espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse SPI_PAD_CONFIG_CS0 22 If you do it right, it will look like this: Config fuses: XPD_SDIO_FORCE Ignore MTDI pin (GPIO12) for VDD_SDIO on reset = 1 R/W (0x1) XPD_SDIO_REG If XPD_SDIO_FORCE, enable VDD_SDIO reg on reset = 1 R/W (0x1) XPD_SDIO_TIEH If XPD_SDIO_FORCE & XPD_SDIO_REG, 1=3.3V 0=1.8V = 1 R/W (0x1) SPI_PAD_CONFIG_CLK Override SD_CLK pad (GPIO6/SPICLK) = 6 R/W (0x6) SPI_PAD_CONFIG_Q Override SD_DATA_0 pad (GPIO7/SPIQ) = 7 R/W (0x7) SPI_PAD_CONFIG_D Override SD_DATA_1 pad (GPIO8/SPID) = 8 R/W (0x8) SPI_PAD_CONFIG_HD Override SD_DATA_2 pad (GPIO9/SPIHD) = 9 R/W (0x9) SPI_PAD_CONFIG_CS0 Override SD_CMD pad (GPIO11/SPICS0) = 22 R/W (0x16) DISABLE_SDIO_HOST Disable SDIO host = 0 R/W (0x0) FIRST TIME BOOT You should see something like this: rst:0x1 (POWERON_RESET),boot:0x1f (SPI_FAST_FLASH_BOOT) I (85) boot: SPI Speed : 40MHz I (85) boot: SPI Mode : DIO I (94) boot: SPI Flash Size : 16MB I (106) boot: Partition Table: I (118) boot: ## Label Usage Type ST Offset Length I (140) boot: 0 nvs WiFi data 01 02 00009000 00004000 I (164) boot: 1 otadata OTA data 01 00 0000d000 00002000 I (187) boot: 2 phy_init RF data 01 01 0000f000 00001000 I (210) boot: 3 factory factory app 00 00 00010000 00400000 I (233) boot: 4 ota_0 OTA app 00 10 00410000 00400000 I (257) boot: 5 ota_1 OTA app 00 11 00810000 00400000 I (280) boot: 6 store Unknown data 01 82 00c10000 00100000 Initialising COMMAND Framework Initialising METRICS Framework Initialising OVMS Peripherals... SPI bus... MAX7317 I/O Expander... ESP32 CAN... ESP32 ADC... MCP2515 CAN 1/2... MCP2515 CAN 2/2... SD CARD... Initialising TEST Framework Initialising SD CARD Framework Initialising MAX7317 EGPIO Framework Initialising VFS Framework Registering Vehicle: Tesla Roadster Initialising HOUSEKEEPING Framework... I (1657) cpu_start: Starting scheduler on PRO CPU. I (509) cpu_start: Starting scheduler on APP CPU. Welcome to the Open Vehicle Monitoring System (OVMS) - async console OVMS > CONSOLE First thing you’ll see if we’ve unified everything into a command console. This console can be accessed over USB, and in future we’ll support WIFI, BLUETOOTH, SMS, GPRS, etc. The point is that all console commands work the same, no matter where they are called from. All core functionality will be exposed via console commands. Here is an example session (live from my test system): Welcome to the Open Vehicle Monitoring System (OVMS) - async console OVMS > sd mount Name: SD Type: SDHC/SDXC Speed: default speed Size: 15120MB CSD: ver=1, sector_size=512, capacity=30965760 read_bl_len=9 SCR: sd_spec=2, bus_width=5 Mounted SD CARD OVMS > vfs ls /sdcard SPOTLI~1 VFS.CPP COMMAND.CPP COMMAND.H COMPON~1.MK CONSOL~1.CPP CONSOL~1.H METRICS.CPP METRICS.H OVMS.H OVMS_M~1.CPP PERIPH~1.CPP PERIPH~1.H TERMINAL.CPP TERMINAL.H TEST_F~1.CPP TEST_F~1.H OVMS > vfs rm /sdcard/OVMS.H VFS File deleted OVMS > egpio output 1 255 EGPIO port 1 set to output level 255 OVMS > sd unmount Unmounted SD CARD OVMS > metrics list m.version v.b.12v 0 v.b.cac v.b.range.e v.b.range.i v.b.soc v.b.soh v.b.temp.ambient v.b.temp.charger v.b.temp.motor v.b.temp.pem v.p.altitude v.p.direction v.p.latitude v.p.longitude v.p.odometer v.p.speed v.p.trip v.tp.fl.p v.tp.fl.t v.tp.fr.p v.tp.fr.t v.tp.rl.p v.tp.rl.t v.tp.rr.p v.tp.rr.t v.type v.vin OVMS > ? egpio EGPIO framework help Ask for help metrics METRICS framework sd SD CARD framework test Test framework vfs VFS framework Tab completion is not done yet, but you can do a “?” to see what is available. METRICS You’ll see these metrics as a new thing in OVMS v3. The idea is that rather than having hard-coded items, we have a dynamic extendable list of metrics. Some are standard (look in metrics_standard.h), but others can be added by vehicle modules (or any part of the system, really). These metrics will be used for MQTT, but also joined back together into groups for OVMS v2 protocol. LANGUAGE The code is in C++. The choice there was because (a) I wanted collections (maps, arrays, etc), (b) I wanted components to be able to self-register without having to change the framework (you just put the component in the right place and it merges itself into the system). Most of the code itself is basic C. CODE STRUCTURE The ‘main’ directory contains the framework itself. Only people playing with the framework should have to change that. The ‘components’ directory contains the extension components. This is where the system is extended. Within ‘main’, we have: command.cpp - the console command processor config.cpp - the configuration system console_async.cpp - an async console for USB port housekeeping.cpp - housekeeping tasks (e.g. measuring the 12v level every few seconds and updating the v.b.12v metric) metrics.cpp - the metrics system metrics_standard.h - the standard metrics ovms_main.cpp - the main entry point peripherals.cpp - access to all the peripherals in the system terminal.cpp - an experiment that didn’t work and will go soon test_framework.cpp - test framework for QC vfs.cpp - access to the virtual filesystem (from console) Within ‘components’, we have: can - a unified interface to CAN buses esp32can - CAN bus native to the ESP32 mcp2515 - CAN bus on the MCP2515 chips, controlled by SPI esp32adc - The ADC (for measuring 12v voltage level) max7317 - The extended GPIO (EGPIO), controlled by SPI microrl - A command line processing library pcp - Power Controlled Peripheral (a base layer for all out peripherals so we can power control them in a unified way) sdcard - SD CARD control spinodma - A SPI master driver that doesn’t use DMA (suitable for the small transfers we do) and is extendable beyond the hardware limit of 3 devices per SPI bus vehicle - The base vehicle layer vehicle_teslaroadster - An example project to add vehicle support for Tesla Roadster There are some code consistency issues at the moment. Things like lowercasevariables vs ThoseLikeThis. I’m trying to clean that up, as the code has come from lots of different places. CHANGES.TXT There is a CHANGES.TXT file. As I make changes (or incorporate other people’s changes), I’ll update it. TODO.TXT There is a list of tasks outstanding in TODO.TXT. If anything interests you, please let me know and I’ll be happy to assign it to you (as well as extremely grateful :-). I’m still trying to validate all the hardware, and ensure everything works. That means moving over the test code I have into proper libraries in this framework, and implement test_framework, or other, commands to allow them to be tested. Some are stubs, but most in the OVMS.V3 github are now live and working. See TODO.TXT for the latest status. Enjoy, Mark.
Mark, I've pulled down the code and built it and loaded it successfully on the DEVKIT-C per your instructions. I have mine mounted on a breadboard and could add the 16MB RAM, but the chip you reference seems not to be available from DigiKey, Mouser, etc. Google only lists hkinventory.com as a source. Are there some available mounted on a breakout board suitable for use in the breadboard? I am able to solder an SOIC device to a breakout board if needed. Or are you planning to distribute OVMSv3 prototypes in a similar timeframe? Looking over the TODO list, perhaps some thing in the Console/Command section would be a good place for me to start? -- Steve
Steve, Just double-checked my instructions. I said set flash size to 1MB, but meant 4MB. That’ll work better for DEVKIT-C. I think if you change partitions.csv to this, it should work ok in 4MB flash: # OVMS 16MB flash ESP32 Partition Table # Name, Type, SubType, Offset, Size nvs, data, nvs, 0x9000, 0x4000 otadata, data, ota, 0xd000, 0x2000 phy_init, data, phy, 0xf000, 0x1000 factory, app, factory, 0x10000, 0x280000 store, data, spiffs, , 1M I haven’t tested, but that seems about right. 2.5MB for the factory app, no OTA, and 1M to be ready for spiffs (config) when it comes. I got my 16MB (128Mbit) flash chips from aliexpress/taobao. It seems that the winbond stuff is more popular in China. If you stay helping out on the framework side of things for the moment, the 4MB DEVKIT-C should be fine. Only pain is having to hold down that BOOT button to flash it (which newer modules, including OVMS v3, avoid with better transistor logic). Helping out on the framework would be really useful. Would free me up some time to work on the other impacting stuff (in particular SPI and power consumption are the most pressing). If you could work on the console/command system, that would be wonderful. The basics are there, but some polishing would be most appreciated. In particular: Microrl tab expansion Microrl has a tab expansion callback mechanism (set callback with microrl_set_complete_callback). That would presumably need to be able to ask the command system for completion results, and return them to microrl. Not too difficult, and perhaps a good starting point. This is in command.{h,cpp} and console.{h,cpp}. Microrl cursor history display bug It seems that ESP32 console (printf, etc) does buffering. I worked around that with a fflush(stdout) in appropriate places, but there is one place it still doesn’t seem to work correctly. Type “help” as an example command. Then cursor-up, and the display doesn’t change. But, press ENTER and “help” command is displayed and run. It seems that cursor up/down history recall is always one line behind the actual history recalled. I’m guessing this is to do with buffering, but maybe completely unrelated. This would be a good one to fix. This is in console_async.{h,cpp} and the microrl component. Command argument specification Currently, we register commands with "RegisterCommand(std::string name, std::string title, void (*execute)(int, OvmsWriter*, int, const char* const*))”. It would be good to have commands also register the minimum and maximum number of parameters they expect (and store in class OvmsCommand). Then, when a command is executed, validate the parameters centrally and output errors if the parameters supplied don’t match. That way, we don’t need to validate them in each and every command implementation. This is in command.{h,cpp}, as well as anywhere that calls RegisterCommand (although presumably if we put the parameters on the end of the RegisterCommand list with =-1 as defaults, to signify no limit, or minimum=0 maximum=999?, we could have sensible defaults that wouldn’t require changing everything). With that, the command/console system would be pretty complete. The only other thing on that is the ‘alert/progress messages’ thing (which is about interrupting the entry of a command to display an alert/progress message, then re-drawing the command input and letting the user carry on typing). I just haven’t thought much about how to actually implement that. It is related to the event system, but also the ability for commands to start tasks that feedback data after the command has completed. In general, you need to have a github account and clone the Open-Vehicle-Monitoring-System-3 project to your own account, then pull from there. When you make a change, make it to your own clone. Then, when you have something to contribute back, you send us a pull request (using github). I’ve explained that really badly, but hopefully you get the idea. Regards, Mark.
On 3 Jul 2017, at 1:22 AM, Stephen Casner <casner@acm.org> wrote:
Mark,
I've pulled down the code and built it and loaded it successfully on the DEVKIT-C per your instructions. I have mine mounted on a breadboard and could add the 16MB RAM, but the chip you reference seems not to be available from DigiKey, Mouser, etc. Google only lists hkinventory.com as a source. Are there some available mounted on a breakout board suitable for use in the breadboard? I am able to solder an SOIC device to a breakout board if needed. Or are you planning to distribute OVMSv3 prototypes in a similar timeframe?
Looking over the TODO list, perhaps some thing in the Console/Command section would be a good place for me to start?
-- Steve _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Mark, build environment up & running, V3 framework builds without problems. But I've got no DevKitC, it's unavailable here, would need to dig into compatible ones. I second the question / wish about developing directly on the V3... :) Regards, Michael Am 02.07.2017 um 16:26 schrieb Mark Webb-Johnson:
To get it up and running on a DEVKIT-C style device
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
I feel your pain. The board I have is working fine - but I just need to be 100% sure we can get the power consumption down to near-zero in a deep sleep, before I ask China to build a bunch. I don’t want to deliver boards to you that need hardware modification in the long-term. For that, I need to get all the peripherals to sleep, and for that I need SPI working, and for that … you get the idea. I’m close. MAX7317 SPI is now working, so I’m now on MCP2515 SPI (which is a lot more complex, as it relies on the unified CAN framework and that means esp32can library). Anyway, I’ll know maybe tonight / tomorrow whether the SPI peripherals can be powered down. That just leaves the CP2102 (USB/UART) and BTS452R. I originally thought the problem was with the CP2102, but that seems to be only 5mA of the problem. We’re also seeing 20mA on the BTS452R, but that makes no sense at all (as it is just a smart mosfet++). If there any hardware gurus here who want to look at the circuit layout and tell me what’s wrong with the BTS452R arrangement, I’ve attached the latest layout diagram. Regards, Mark.
On 3 Jul 2017, at 4:16 AM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
build environment up & running, V3 framework builds without problems.
But I've got no DevKitC, it's unavailable here, would need to dig into compatible ones.
I second the question / wish about developing directly on the V3... :)
Regards, Michael
Am 02.07.2017 um 16:26 schrieb Mark Webb-Johnson:
To get it up and running on a DEVKIT-C style device
-- 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
Have you grounded pin4 "ST" diagnostic output? It's not on the schematic, so depends what is on the pcb... Edward
On 3/07/2017, at 6:21 PM, Mark Webb-Johnson wrote:
I feel your pain. The board I have is working fine - but I just need to be 100% sure we can get the power consumption down to near-zero in a deep sleep, before I ask China to build a bunch. I don’t want to deliver boards to you that need hardware modification in the long-term.
For that, I need to get all the peripherals to sleep, and for that I need SPI working, and for that … you get the idea. I’m close. MAX7317 SPI is now working, so I’m now on MCP2515 SPI (which is a lot more complex, as it relies on the unified CAN framework and that means esp32can library).
Anyway, I’ll know maybe tonight / tomorrow whether the SPI peripherals can be powered down. That just leaves the CP2102 (USB/UART) and BTS452R. I originally thought the problem was with the CP2102, but that seems to be only 5mA of the problem. We’re also seeing 20mA on the BTS452R, but that makes no sense at all (as it is just a smart mosfet++).
If there any hardware gurus here who want to look at the circuit layout and tell me what’s wrong with the BTS452R arrangement, I’ve attached the latest layout diagram.
Regards, Mark.
<OVMS_V3_Layout_CN_20170615.pdf>
On 3 Jul 2017, at 4:16 AM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
build environment up & running, V3 framework builds without problems.
But I've got no DevKitC, it's unavailable here, would need to dig into compatible ones.
I second the question / wish about developing directly on the V3... :)
Regards, Michael
Am 02.07.2017 um 16:26 schrieb Mark Webb-Johnson: To get it up and running on a DEVKIT-C style device
-- 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
Also, as pin3 is a stub that doesn't reach the board, is the tab connected in its place? Plenty to go wrong between schematic and pcb with missing pin devices!
On 3/07/2017, at 6:59 PM, Edward Cheeseman wrote:
Have you grounded pin4 "ST" diagnostic output? It's not on the schematic, so depends what is on the pcb...
Edward
On 3/07/2017, at 6:21 PM, Mark Webb-Johnson wrote:
I feel your pain. The board I have is working fine - but I just need to be 100% sure we can get the power consumption down to near-zero in a deep sleep, before I ask China to build a bunch. I don’t want to deliver boards to you that need hardware modification in the long-term.
For that, I need to get all the peripherals to sleep, and for that I need SPI working, and for that … you get the idea. I’m close. MAX7317 SPI is now working, so I’m now on MCP2515 SPI (which is a lot more complex, as it relies on the unified CAN framework and that means esp32can library).
Anyway, I’ll know maybe tonight / tomorrow whether the SPI peripherals can be powered down. That just leaves the CP2102 (USB/UART) and BTS452R. I originally thought the problem was with the CP2102, but that seems to be only 5mA of the problem. We’re also seeing 20mA on the BTS452R, but that makes no sense at all (as it is just a smart mosfet++).
If there any hardware gurus here who want to look at the circuit layout and tell me what’s wrong with the BTS452R arrangement, I’ve attached the latest layout diagram.
Regards, Mark.
<OVMS_V3_Layout_CN_20170615.pdf>
On 3 Jul 2017, at 4:16 AM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
build environment up & running, V3 framework builds without problems.
But I've got no DevKitC, it's unavailable here, would need to dig into compatible ones.
I second the question / wish about developing directly on the V3... :)
Regards, Michael
Am 02.07.2017 um 16:26 schrieb Mark Webb-Johnson: To get it up and running on a DEVKIT-C style device
-- 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
Attached is the board layout, if it helps. Thanks for the hints. I will check on the physical board with a multi-meter. From my memory, the tab went to Vbb and pin #3 was floating in the air. Regards, Mark. P.S. If I ground pin #4 (ST) and power consumption drops 20mA, I’ll owe you more than a beer :-)
On 3 Jul 2017, at 3:01 PM, Edward Cheeseman <cheesemanedward@gmail.com> wrote:
Also, as pin3 is a stub that doesn't reach the board, is the tab connected in its place? Plenty to go wrong between schematic and pcb with missing pin devices!
On 3/07/2017, at 6:59 PM, Edward Cheeseman wrote:
Have you grounded pin4 "ST" diagnostic output? It's not on the schematic, so depends what is on the pcb...
Edward
On 3/07/2017, at 6:21 PM, Mark Webb-Johnson wrote:
I feel your pain. The board I have is working fine - but I just need to be 100% sure we can get the power consumption down to near-zero in a deep sleep, before I ask China to build a bunch. I don’t want to deliver boards to you that need hardware modification in the long-term.
For that, I need to get all the peripherals to sleep, and for that I need SPI working, and for that … you get the idea. I’m close. MAX7317 SPI is now working, so I’m now on MCP2515 SPI (which is a lot more complex, as it relies on the unified CAN framework and that means esp32can library).
Anyway, I’ll know maybe tonight / tomorrow whether the SPI peripherals can be powered down. That just leaves the CP2102 (USB/UART) and BTS452R. I originally thought the problem was with the CP2102, but that seems to be only 5mA of the problem. We’re also seeing 20mA on the BTS452R, but that makes no sense at all (as it is just a smart mosfet++).
If there any hardware gurus here who want to look at the circuit layout and tell me what’s wrong with the BTS452R arrangement, I’ve attached the latest layout diagram.
Regards, Mark.
<OVMS_V3_Layout_CN_20170615.pdf>
On 3 Jul 2017, at 4:16 AM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
build environment up & running, V3 framework builds without problems.
But I've got no DevKitC, it's unavailable here, would need to dig into compatible ones.
I second the question / wish about developing directly on the V3... :)
Regards, Michael
Am 02.07.2017 um 16:26 schrieb Mark Webb-Johnson: To get it up and running on a DEVKIT-C style device
-- 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
No I think ST shouldn't be connected to ground. The pcb output didn't have the ground net so couldn't tell so check to make sure. What is more likely the problem is the device has an input resistance and constant current sink. The max7137 output is open drain with the 10k pull-up. 10k may be upsetting the mosfet charge pump. Try removing R9 to see if current consumption drops. Unfortunately it looks like you need to drive the pin high with an output. Maybe use a pmos (e.g. bss223bw) connected D-> IN pin, S->3V3, G-> R9 and max7137. Edward
On 3/07/2017, at 7:17 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Attached is the board layout, if it helps.
Thanks for the hints. I will check on the physical board with a multi-meter. From my memory, the tab went to Vbb and pin #3 was floating in the air.
Regards, Mark.
P.S. If I ground pin #4 (ST) and power consumption drops 20mA, I’ll owe you more than a beer :-)
<OVMS_V3_Board_CN_20170615.pdf>
On 3 Jul 2017, at 3:01 PM, Edward Cheeseman <cheesemanedward@gmail.com> wrote:
Also, as pin3 is a stub that doesn't reach the board, is the tab connected in its place? Plenty to go wrong between schematic and pcb with missing pin devices!
On 3/07/2017, at 6:59 PM, Edward Cheeseman wrote:
Have you grounded pin4 "ST" diagnostic output? It's not on the schematic, so depends what is on the pcb...
Edward
On 3/07/2017, at 6:21 PM, Mark Webb-Johnson wrote:
I feel your pain. The board I have is working fine - but I just need to be 100% sure we can get the power consumption down to near-zero in a deep sleep, before I ask China to build a bunch. I don’t want to deliver boards to you that need hardware modification in the long-term.
For that, I need to get all the peripherals to sleep, and for that I need SPI working, and for that … you get the idea. I’m close. MAX7317 SPI is now working, so I’m now on MCP2515 SPI (which is a lot more complex, as it relies on the unified CAN framework and that means esp32can library).
Anyway, I’ll know maybe tonight / tomorrow whether the SPI peripherals can be powered down. That just leaves the CP2102 (USB/UART) and BTS452R. I originally thought the problem was with the CP2102, but that seems to be only 5mA of the problem. We’re also seeing 20mA on the BTS452R, but that makes no sense at all (as it is just a smart mosfet++).
If there any hardware gurus here who want to look at the circuit layout and tell me what’s wrong with the BTS452R arrangement, I’ve attached the latest layout diagram.
Regards, Mark.
<OVMS_V3_Layout_CN_20170615.pdf>
On 3 Jul 2017, at 4:16 AM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
build environment up & running, V3 framework builds without problems.
But I've got no DevKitC, it's unavailable here, would need to dig into compatible ones.
I second the question / wish about developing directly on the V3... :)
Regards, Michael
Am 02.07.2017 um 16:26 schrieb Mark Webb-Johnson: To get it up and running on a DEVKIT-C style device
-- 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
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Thanks. That makes sense. I’ve passed this on to the China side to see what they suggest as the simplest solution. The good news is we’ve found the issue with the CP2102. We’ve now re-worked that to be purely USB powered, and now when we power from 12V, that consumption falls to ZERO. So in the normal use case of 12V power from the car, the CP2102 will be powered off completely. That saves us 5mA in deep sleep. Regards, Mark.
On 3 Jul 2017, at 3:51 PM, Edward Cheeseman <cheesemanedward@gmail.com> wrote:
No I think ST shouldn't be connected to ground. The pcb output didn't have the ground net so couldn't tell so check to make sure.
What is more likely the problem is the device has an input resistance and constant current sink. The max7137 output is open drain with the 10k pull-up. 10k may be upsetting the mosfet charge pump. Try removing R9 to see if current consumption drops. Unfortunately it looks like you need to drive the pin high with an output. Maybe use a pmos (e.g. bss223bw) connected D-> IN pin, S->3V3, G-> R9 and max7137.
Edward
On 3/07/2017, at 7:17 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Attached is the board layout, if it helps.
Thanks for the hints. I will check on the physical board with a multi-meter. From my memory, the tab went to Vbb and pin #3 was floating in the air.
Regards, Mark.
P.S. If I ground pin #4 (ST) and power consumption drops 20mA, I’ll owe you more than a beer :-)
<OVMS_V3_Board_CN_20170615.pdf>
On 3 Jul 2017, at 3:01 PM, Edward Cheeseman <cheesemanedward@gmail.com> wrote:
Also, as pin3 is a stub that doesn't reach the board, is the tab connected in its place? Plenty to go wrong between schematic and pcb with missing pin devices!
On 3/07/2017, at 6:59 PM, Edward Cheeseman wrote:
Have you grounded pin4 "ST" diagnostic output? It's not on the schematic, so depends what is on the pcb...
Edward
On 3/07/2017, at 6:21 PM, Mark Webb-Johnson wrote:
I feel your pain. The board I have is working fine - but I just need to be 100% sure we can get the power consumption down to near-zero in a deep sleep, before I ask China to build a bunch. I don’t want to deliver boards to you that need hardware modification in the long-term.
For that, I need to get all the peripherals to sleep, and for that I need SPI working, and for that … you get the idea. I’m close. MAX7317 SPI is now working, so I’m now on MCP2515 SPI (which is a lot more complex, as it relies on the unified CAN framework and that means esp32can library).
Anyway, I’ll know maybe tonight / tomorrow whether the SPI peripherals can be powered down. That just leaves the CP2102 (USB/UART) and BTS452R. I originally thought the problem was with the CP2102, but that seems to be only 5mA of the problem. We’re also seeing 20mA on the BTS452R, but that makes no sense at all (as it is just a smart mosfet++).
If there any hardware gurus here who want to look at the circuit layout and tell me what’s wrong with the BTS452R arrangement, I’ve attached the latest layout diagram.
Regards, Mark.
<OVMS_V3_Layout_CN_20170615.pdf>
On 3 Jul 2017, at 4:16 AM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
build environment up & running, V3 framework builds without problems.
But I've got no DevKitC, it's unavailable here, would need to dig into compatible ones.
I second the question / wish about developing directly on the V3... :)
Regards, Michael
> Am 02.07.2017 um 16:26 schrieb Mark Webb-Johnson: > To get it up and running on a DEVKIT-C style device
-- 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
_______________________________________________ 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
Oh, crap. Someone (probably me) made a typo on the layout. It seems the guys in China working on testing power consumption removed BOTH the BTS452R and R17/R18 voltage divider network and saw a 20mA drop in consumption (and assumed the cause was the BTS452R). Turns out the problem is the R17/R18 voltage divider network. According to simulators: With 475R and 100R, current is 17.39mA. With 475K and 100K, current is 17.39uA. A typo “R” not the same as “K”, and that was about 20mA. With that (silly, annoying, crazy, typo) fixed (changing to 500K and 100K for the voltage divider), we’re now about 13mA, or about 2mA without the MCP2515 and transceivers connected. I think the remaining 10mA or so is the MCP2515 not in sleep mode. But, I’m still fighting the SPI bus control on those. Hopefully will have this final bit nailed in the next 24 hours. Regards, Mark. (and thanks to Edward for stepping in to help)
On 3 Jul 2017, at 3:59 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Thanks. That makes sense. I’ve passed this on to the China side to see what they suggest as the simplest solution.
The good news is we’ve found the issue with the CP2102. We’ve now re-worked that to be purely USB powered, and now when we power from 12V, that consumption falls to ZERO. So in the normal use case of 12V power from the car, the CP2102 will be powered off completely. That saves us 5mA in deep sleep.
Regards, Mark.
On 3 Jul 2017, at 3:51 PM, Edward Cheeseman <cheesemanedward@gmail.com> wrote:
No I think ST shouldn't be connected to ground. The pcb output didn't have the ground net so couldn't tell so check to make sure.
What is more likely the problem is the device has an input resistance and constant current sink. The max7137 output is open drain with the 10k pull-up. 10k may be upsetting the mosfet charge pump. Try removing R9 to see if current consumption drops. Unfortunately it looks like you need to drive the pin high with an output. Maybe use a pmos (e.g. bss223bw) connected D-> IN pin, S->3V3, G-> R9 and max7137.
Edward
On 3/07/2017, at 7:17 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Attached is the board layout, if it helps.
Thanks for the hints. I will check on the physical board with a multi-meter. From my memory, the tab went to Vbb and pin #3 was floating in the air.
Regards, Mark.
P.S. If I ground pin #4 (ST) and power consumption drops 20mA, I’ll owe you more than a beer :-)
<OVMS_V3_Board_CN_20170615.pdf>
On 3 Jul 2017, at 3:01 PM, Edward Cheeseman <cheesemanedward@gmail.com> wrote:
Also, as pin3 is a stub that doesn't reach the board, is the tab connected in its place? Plenty to go wrong between schematic and pcb with missing pin devices!
On 3/07/2017, at 6:59 PM, Edward Cheeseman wrote:
Have you grounded pin4 "ST" diagnostic output? It's not on the schematic, so depends what is on the pcb...
Edward
On 3/07/2017, at 6:21 PM, Mark Webb-Johnson wrote:
I feel your pain. The board I have is working fine - but I just need to be 100% sure we can get the power consumption down to near-zero in a deep sleep, before I ask China to build a bunch. I don’t want to deliver boards to you that need hardware modification in the long-term.
For that, I need to get all the peripherals to sleep, and for that I need SPI working, and for that … you get the idea. I’m close. MAX7317 SPI is now working, so I’m now on MCP2515 SPI (which is a lot more complex, as it relies on the unified CAN framework and that means esp32can library).
Anyway, I’ll know maybe tonight / tomorrow whether the SPI peripherals can be powered down. That just leaves the CP2102 (USB/UART) and BTS452R. I originally thought the problem was with the CP2102, but that seems to be only 5mA of the problem. We’re also seeing 20mA on the BTS452R, but that makes no sense at all (as it is just a smart mosfet++).
If there any hardware gurus here who want to look at the circuit layout and tell me what’s wrong with the BTS452R arrangement, I’ve attached the latest layout diagram.
Regards, Mark.
<OVMS_V3_Layout_CN_20170615.pdf>
> On 3 Jul 2017, at 4:16 AM, Michael Balzer <dexter@expeedo.de> wrote: > > Mark, > > build environment up & running, V3 framework builds without problems. > > But I've got no DevKitC, it's unavailable here, would need to dig into > compatible ones. > > I second the question / wish about developing directly on the V3... :) > > Regards, > Michael > > >> Am 02.07.2017 um 16:26 schrieb Mark Webb-Johnson: >> To get it up and running on a DEVKIT-C style device > > -- > 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
_______________________________________________ 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
participants (4)
-
Edward Cheeseman -
Mark Webb-Johnson -
Michael Balzer -
Stephen Casner