<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 9 Jun 2017, at 1:41 PM, Mark Webb-Johnson <<a href="mailto:mark@webb-johnson.net" class="">mark@webb-johnson.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Just a short update on progress.<div class=""><br class=""></div><div class="">It was painful, but we’ve finished the validation of the OVMS v3 board. Only one ESP32 was blown in the entire testing process ;-) [ <i class="">Putting a 12V pin just next to a 3.3V pin on the switched 12V probably wasn’t such a smart idea.</i> ] Oh well, at least I had fun with a microscope and some SMT soldering skills.</div><div class=""><br class=""></div><div class="">Some nasty bugs and documentation issues on the ESP32 side of things, as well as an inadvertently swapped pair of MOSI / MISO pins caused endless issues. Thank Saleae for logic analysers.</div><div class=""><br class=""></div><div class=""><span id="cid:3B8D9C82-A92C-40C0-929E-0934DCEF7C4F"><image2.jpeg></span></div><div class=""><br class=""></div><div class="">Really rather cool to watch the logic analyser display SPI bus traffic to/from the MCP2515, then CAN bus output of the message itself.</div><div class=""><br class=""></div><div class="">Most of the issues we’ve been having are because the ESP32 internal pull-up system just doesn’t seem to be working well. Some of the GPIO pins have to use the RTC side to do pull-up, and behave the worst. We often get 2.1V, not 3.3V, measured; and it just doesn’t seem reliable (especially on the high speed side such as SPI and SD-card access). Switching to physical pull-ups resolve these issues, so that is what we are doing. There were also issues with dual-purposes GPIO lines used during bootstrapping. For example, the GPIO2 line (which must be low during boot for firmware download), and GPIO12 (which is used during boot for 1.8v / 3.3v flash selection). We’re also going to prepare pull-up pads for the other lines, and some test clip connection points, but leave them unpopulated - should be easier to change things in future, if necessary.</div><div class=""><br class=""></div><div class="">To keep the high-speed SPI buses used to talk to the MCP2515 and MAX7317 short and clean, we’ve had to remove those three pins from the DB26 external expansion connector. It just seemed to be causing too much interference. These pins are still available on the expansion slot(s), and the SPI master driver we have switched to supports software control of the CS lines, so can support more than 3 SPI slaves on one master.</div><div class=""><br class=""></div><div class="">Here is the current status:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">Power supply: vehicle 12V</li><ul class=""><li class="">3.3V: 3.300V measured and very stable - <b class=""><font color="#00f900" class="">pass</font></b></li><li class="">EXT_PWR: 11.704V measured - <b class=""><font color="#00f900" class="">pass</font></b></li><li class="">EXT_12V: 12.002V measured - <b class=""><font color="#00f900" class="">pass</font></b></li><li class="">USB_5V: 0.7013V measured (floating?) - <b class=""><font color="#00f900" class="">pass</font></b></li></ul><li class="">Power supply: USB 5V</li><ul class=""><li class="">3.3V: 3.301V measured and very stable - <b class=""><font color="#00f900" class="">pass</font></b></li><li class="">EXT_PWR: 4.525V measured - <b class=""><font color="#00f900" class="">pass</font></b></li><li class="">EXT_12V: 0.0012V measured - <b class=""><font color="#00f900" class="">pass</font></b></li><li class="">USB_5V: 4.810V measured - <b class=""><font color="#00f900" class="">pass</font></b></li></ul><li class="">Power supply: vehicle 12V and USB 5V</li><ul class=""><li class="">3.3V: 3.301V measured and very stable - <b class=""><font color="#00f900" class="">pass</font></b></li><li class="">EXT_PWR: 11.771V measured - <b class=""><font color="#00f900" class="">pass</font></b></li><li class="">EXT_12V: 12.031V measured - <b class=""><font color="#00f900" class="">pass</font></b></li><li class="">USB_5V: 4.838V measured - <b class=""><font color="#00f900" class="">pass</font></b></li></ul><li class="">Reset Button</li><ul class=""><li class="">Tested ok - <b class=""><font color="#00f900" class="">pass</font></b></li></ul><li class="">Boot Button</li><ul class=""><li class="">Tested ok - <b class=""><font color="#00f900" class="">pass</font></b></li></ul><li class="">CP2102</li><ul class=""><li class="">Async comms: Tested ok - <b class=""><font color="#00f900" class="">pass</font></b></li><li class="">Automatic firmware download: Tested ok - <b class=""><font color="#00f900" class="">pass</font></b></li></ul><li class="">Wifi</li><ul class=""><li class="">Tested ok - <b class=""><font color="#00f900" class="">pass</font></b></li></ul><li class="">Bluetooth</li><ul class=""><li class="">Tested ok - <b class=""><font color="#00f900" class="">pass</font></b></li></ul><li class="">External flash</li><ul class=""><li class="">Special ESP32 fuse settings required</li><li class="">Tested ok - <b class=""><font color="#00f900" class="">pass</font></b></li></ul><li class="">SD-CARD<br class=""></li><ul class=""><li class="">1-line mode: physical pull-ups added - <b class=""><font color="#00f900" class="">pass</font></b></li><ul class=""><li class="">10K pull-up needed on GPIO14, GPIO15, GPIO4, GPIO13</li><li class="">Link required between GPIO0 and GPIO2</li><li class="">Special pull up and fuse setting arrangement needed for GPIO12</li></ul><li class="">4-line mode: physical pull-ups added - <b class=""><font color="#00f900" class="">pass</font></b></li><ul class=""><li class="">10K pull-up needed on GPIO14, GPIO15, GPIO4, GPIO13</li><li class="">Link required between GPIO0 and GPIO2</li><li class="">Special pull up and fuse setting arrangement needed for GPIO12</li></ul></ul><li class="">ESP32 CAN bus #0 - <b class=""><font color="#00f900" class="">pass</font></b></li><ul class=""><li class="">1MHz bus speed</li><ul class=""><li class="">Transmit: Working perfectly - <b class=""><font color="#00f900" class="">pass</font></b></li><li class="">Receive: Working perfectly - <b class=""><font color="#00f900" class="">pass</font></b></li></ul></ul><li class="">MCP2515 CAN bus #1</li><ul class=""><li class="">SPI MOSI/MISO swapped</li><li class="">1MHz bus speed</li><ul class=""><li class="">Transmit: Working perfectly - <b class=""><font color="#00f900" class="">pass</font></b></li><li class="">Receive: Working perfectly - <b class=""><font color="#00f900" class="">pass</font></b></li></ul></ul><li class="">MCP2515 CAN bus #2</li><ul class=""><li class="">SPI MOSI/MISO swapped</li><li class="">1MHz bus speed</li><ul class=""><li class="">Transmit: Working perfectly - <b class=""><font color="#00f900" class="">pass</font></b></li><li class="">Receive: Working perfectly - <b class=""><font color="#00f900" class="">pass</font></b></li></ul></ul><li class="">MAX7317</li><ul class=""><li class="">Remove pull-down to GND on SW_CTL, and add physical pull-up.</li><li class="">Add pull-up on SP_CS3.</li><li class="">Tested, and works ok - <b class=""><font color="#00f900" class="">pass</font></b></li></ul><li class="">Vehicle 9 pin port</li><ul class=""><li class="">Visually ok - <b class=""><font color="#00f900" class="">pass</font></b></li><li class="">Connections ok</li></ul><li class="">Expansion 26 pin port</li><ul class=""><li class="">Visually ok - <b class=""><font color="#00f900" class="">pass</font></b></li><li class="">SPI MOSI/MISO swapped</li><li class="">Connections ok</li></ul><li class="">USB port</li><ul class=""><li class="">Visually ok - <b class=""><font color="#00f900" class="">pass</font></b></li><li class="">To change to a physically stronger port (or mounting arrangement)</li></ul><li class="">Expansion slot #1</li><ul class=""><li class="">Visually ok - <b class=""><font color="#00f900" class="">pass</font></b></li></ul><li class="">Expansion slot #2</li><ul class=""><li class="">Visually ok - <b class=""><font color="#00f900" class="">pass</font></b></li><li class="">To be removed in production board</li></ul></ul><div class=""><br class=""></div></div><div class="">Burning the ESP32 fuses was exciting. This is a one-time operation with no way back. It is literally passing too much current through some little wires in the chip, to burn through and break the wire. Blowing the fuse. Once we do it, here is what we get:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Andale Mono" class=""><span class="" style="font-size: 14px;">$ espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse XPD_SDIO_REG 1</span></font></div><div class=""><font face="Andale Mono" class=""><span class="" style="font-size: 14px;">$ </span></font><span style="font-family: 'Andale Mono'; font-size: 14px;" class="">espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse XPD_SDIO_TIEH 1</span></div><div class=""><span style="font-family: 'Andale Mono'; font-size: 14px;" class="">$ </span><span style="font-family: 'Andale Mono'; font-size: 14px;" class="">espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse XPD_SDIO_FORCE 1</span></div><div class=""><span style="font-family: 'Andale Mono'; font-size: 14px;" class=""><br class=""></span></div><div class=""><span style="font-family: 'Andale Mono'; font-size: 14px;" class="">$ espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse SPI_PAD_CONFIG_CLK 6</span></div><div class=""><span style="font-family: 'Andale Mono'; font-size: 14px;" class="">$ </span><span style="font-family: 'Andale Mono'; font-size: 14px;" class="">espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse SPI_PAD_CONFIG_Q 7</span></div><div class=""><span style="font-family: 'Andale Mono'; font-size: 14px;" class="">$ </span><span style="font-family: 'Andale Mono'; font-size: 14px;" class="">espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse SPI_PAD_CONFIG_D 8</span></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class="">$ </span></font><span style="font-family: 'Andale Mono'; font-size: 14px;" class="">espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse SPI_PAD_CONFIG_HD 9</span></div></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class="">$ </span></font><span style="font-family: 'Andale Mono'; font-size: 14px;" class="">espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse SPI_PAD_CONFIG_CS0 22</span></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class=""><br class=""></span></font><div class=""><font face="Andale Mono" class=""><span class="" style="font-size: 14px;">$ espefuse.py -p /dev/tty.SLAB_USBtoUART summary</span></font></div><div class=""><font face="Andale Mono" class=""><span class="" style="font-size: 14px;"><div class="">XPD_SDIO_FORCE Ignore MTDI pin (GPIO12) for VDD_SDIO on reset = 1 R/W (0x1)</div><div class="">XPD_SDIO_REG If XPD_SDIO_FORCE, enable VDD_SDIO reg on reset = 1 R/W (0x1)</div><div class="">XPD_SDIO_TIEH If XPD_SDIO_FORCE & XPD_SDIO_REG, 1=3.3V 0=1.8V = 1 R/W (0x1)</div><div class=""><div class="" style="font-family: Helvetica; font-size: 24px;"><font face="Andale Mono" class=""><span class="" style="font-size: 14px;"><br class=""></span></font></div><div class="" style="font-family: Helvetica; font-size: 24px;"><font face="Andale Mono" class=""><span class="" style="font-size: 14px;">SPI_PAD_CONFIG_CLK Override SD_CLK pad (GPIO6/SPICLK) = 6 R/W (0x6)</span></font></div><div class="" style="font-family: Helvetica; font-size: 24px;"><font face="Andale Mono" class=""><span class="" style="font-size: 14px;">SPI_PAD_CONFIG_Q Override SD_DATA_0 pad (GPIO7/SPIQ) = 7 R/W (0x7)</span></font></div><div class="" style="font-family: Helvetica; font-size: 24px;"><font face="Andale Mono" class=""><span class="" style="font-size: 14px;">SPI_PAD_CONFIG_D Override SD_DATA_1 pad (GPIO8/SPID) = 8 R/W (0x8)</span></font></div><div class="" style="font-family: Helvetica; font-size: 24px;"><font face="Andale Mono" class=""><span class="" style="font-size: 14px;">SPI_PAD_CONFIG_HD Override SD_DATA_2 pad (GPIO9/SPIHD) = 9 R/W (0x9)</span></font></div><div class="" style="font-family: Helvetica; font-size: 24px;"><font face="Andale Mono" class=""><span class="" style="font-size: 14px;">SPI_PAD_CONFIG_CS0 Override SD_CMD pad (GPIO11/SPICS0) = 22 R/W (0x16)</span></font></div></div></span></font></div></blockquote><div class=""><br class=""></div><div class="">Once that is done, we can simply change to DIO mode for SPI flashing and set flash size to 16MB - it will now use our external 16MB flash and the WROOM-32 4MB flash will not be used. In theory, we should still be able access the WROOM-32 4MB flash in our code, but it is not used by the system. This procedure will be done by the factory, as part of factory firmware load.</div><div class=""><br class=""></div><div class="">So, yesterday I handed the final list of all the above over to the China guys. We’re happy that the board is close enough to try to make a production version, so they are sourcing an enclosure and re-laying everything out to fit and match that. The goal is to get the system about the same height and depth as an OVMS v2 module, just about an inch longer. Biggest constraint seems to be the number and size of external connectors we have.</div><div class=""><br class=""></div><div class="">Here is what I sent China:</div><div class=""><br class=""></div><div class=""><span id="cid:31A7640F-7F02-40FA-BD83-82D35E8FA6F8"><PastedGraphic-1.tiff></span></div><div class=""><br class=""></div><div class="">and this is what they sent back:</div><div class=""><br class=""></div><div class=""><span id="cid:1B0A0CCD-FF1E-4645-ABB5-7024DD52A9F4"><269B1E05-5609-4430-B04B-23D2A314D01E.png></span></div><div class=""><br class=""></div><div class="">Touché, China. You win that one.</div><div class=""><br class=""></div><div class=""><span id="cid:12E025F1-85E2-457B-9659-A3E494823604"><6DBB6579-A139-46BE-8664-2C3B3D74C467.png></span></div><div class=""><br class=""></div><div class="">We’re trying to find some low-profile stacking connectors to keep the depth reasonable.</div><div class=""><br class=""></div><div class="">So, the enclosure selection and final board layout is being drawn up now by the China side. I’m taking a break from banging on SPI buses, and now full-time on the firmware framework.</div><div class=""><br class=""></div><div class="">Regards, Mark.</div><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class=""><div class="">On 22 May 2017, at 10:58 AM, Mark Webb-Johnson <<a href="mailto:mark@webb-johnson.net" class="">mark@webb-johnson.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">I'm still trying to work out the stackable/side-by-side issue.<br class=""><br class="">The thing I didn't like with the stackable option is the height (assuming each expansion module is also stackable). Every time I look at Arduino / Raspberry / etc, I think it is too tall. My problem is that top-most stackable connector that is _always_ empty. I know why it is there - but it just increases the height for the enclosure.<br class=""><br class="">I am thinking that perhaps there is a way out. <br class=""><br class="">What if we used a stackable design, but just have the modem modules non-stackable? The modem always goes on top. That way, the height of a normal system (without expansion modules other than the modem) is mostly unaffected. If an expansion module is required, then it must be stackable and placed between the main board and the modem. The non-stackable modem always on top. So for the 5% of users who use in-the-box expansion, they need a bigger case, but the 95% of other users can go with something slimmer.<br class=""><br class="">Kind of like this: Base board on the bottom, stackable expansion boards in the middle, and non-stackable modem board on top. The top picture shows the 5% case (with stackable expansion module sandwiched), the bottom picture shows the 95% case (with just base and modem).<br class=""><br class="">Size wise, we could go with something more like an Aurduido Due. Wider than OVMS v2, but about the same height and depth.<br class=""><br class="">Thoughts?<br class=""><br class="">Regards, Mark.<br class=""><br class=""><span id="cid:70AA7657-6BAD-44B8-AE97-214BA052167A" class=""><image1.jpeg></span><br class=""><br class=""><span id="cid:C1FFD676-D8F3-4798-971B-D891B558F669" class=""><image2.jpeg></span><br class=""><br class=""><br class=""><blockquote type="cite" class="">On 19 May 2017, at 2:23 PM, Mark Webb-Johnson <<a href="mailto:mark@webb-johnson.net" class="">mark@webb-johnson.net</a>> wrote:<br class=""><br class="">I've got the first OVMS v3 development board in my hands now. The components seem fine, and I'm finalizing the QC program that checks everything to make sure all is ok. 16MB flash with OTA capability, Wifi, Bluetooth, 3xCAN bus, lots of GPIO, switched 12V, power by USB/12V, SD card reader/writer, optional 2G/3G/4G modem (with GPS), two expansion slots, USB, and an external expansion connector - all look good.<br class=""><br class="">Both 3G and 4G development expansion boards are also being made now, and I should have those next week.<br class=""><br class="">But, having seen it and held it, I'm now having second thoughts about the layout. As you can see from the attached pictures, the expansion slots are each about 60mm x 45mm. Putting two of those on the board makes it about 9.5cm x 9.5cm square. Height will be similar (a little bit taller) than the current OVMS v2. This is a first draft run only, just to confirm the components, but as you can see there is quite a lot of blank space and traces for the two expansion slots. That, and the sheer number of connectors we have, dominate the board. Let's call this arrangement (A).<br class=""><br class="">There was an alternative arrangement that I considered a while back. That would be to have just one expansion slot, but use stackable connectors (so multiple boards could be piggybacked on each other). In that arrangement, the expansion slot could be either vertical or horizontal, with a vertical arrangement being close in size to the existing OVMS v2 (but the height would need to be much taller to accommodate the piggybacked expansion boards). Let's call this arrangement (B).<br class=""><br class="">It doesn't change the wiring. Just the size and arrangement of components on the board, as well as the box housing this all. (A) ends up with a 1" wider+taller box of about the same thickness, while (B) ends up with a box about the same width and height, but significantly thicker. To me, it seems that (A) is more automotive, and (B) more hobbyist.<br class=""><br class="">What do people think?<br class=""><br class="">In the meantime, on with development (now that at last I have a target in my hands).<br class=""><br class="">Mark<br class=""><br class=""><image1.jpeg><br class=""><br class=""><image2.jpeg><br class=""><br class=""><image3.jpeg><br class=""><br class=""><image4.jpeg><br class=""><br class=""><image5.jpeg><br class=""><br class=""><image6.jpeg><br class=""><br class=""><image7.jpeg><br class="">_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.teslaclub.hk" class="">OvmsDev@lists.teslaclub.hk</a><br class=""><a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" class="">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br class=""></blockquote>_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.teslaclub.hk" class="">OvmsDev@lists.teslaclub.hk</a><br class=""><a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" class="">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br class=""></div></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.teslaclub.hk" class="">OvmsDev@lists.teslaclub.hk</a><br class="">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br class=""></div></blockquote></div><br class=""></div></body></html>