[Ovmsdev] V3 size and arrangement

Fri Jun 9 13:41:23 HKT 2017

Just a short update on progress.

It was painful, but we’ve finished the validation of the OVMS v3 board. Only one ESP32 was blown in the entire testing process ;-) [ Putting a 12V pin just next to a 3.3V pin on the switched 12V probably wasn’t such a smart idea. ] Oh well, at least I had fun with a microscope and some SMT soldering skills.

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.

Really rather cool to watch the logic analyser display SPI bus traffic to/from the MCP2515, then CAN bus output of the message itself.

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.

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.

Here is the current status:

Power supply: vehicle 12V
3.3V: 3.300V measured and very stable - pass
EXT_PWR: 11.704V measured - pass
EXT_12V: 12.002V measured - pass
USB_5V: 0.7013V measured (floating?) - pass
Power supply: USB 5V
3.3V: 3.301V measured and very stable - pass
EXT_PWR: 4.525V measured - pass
EXT_12V: 0.0012V measured - pass
USB_5V: 4.810V measured - pass
Power supply: vehicle 12V and USB 5V
3.3V: 3.301V measured and very stable - pass
EXT_PWR: 11.771V measured - pass
EXT_12V: 12.031V measured - pass
USB_5V: 4.838V measured - pass
Reset Button
Tested ok - pass
Boot Button
Tested ok - pass
CP2102
Async comms: Tested ok - pass
Automatic firmware download: Tested ok - pass
Wifi
Tested ok - pass
Bluetooth
Tested ok - pass
External flash
Special ESP32 fuse settings required
Tested ok - pass
SD-CARD
1-line mode: physical pull-ups added - pass
10K pull-up needed on GPIO14, GPIO15, GPIO4, GPIO13
Link required between GPIO0 and GPIO2
Special pull up and fuse setting arrangement needed for GPIO12
4-line mode: physical pull-ups added - pass
10K pull-up needed on GPIO14, GPIO15, GPIO4, GPIO13
Link required between GPIO0 and GPIO2
Special pull up and fuse setting arrangement needed for GPIO12
ESP32 CAN bus #0 - pass
1MHz bus speed
Transmit: Working perfectly - pass
Receive: Working perfectly - pass
MCP2515 CAN bus #1
SPI MOSI/MISO swapped
1MHz bus speed
Transmit: Working perfectly - pass
Receive: Working perfectly - pass
MCP2515 CAN bus #2
SPI MOSI/MISO swapped
1MHz bus speed
Transmit: Working perfectly - pass
Receive: Working perfectly - pass
MAX7317
Remove pull-down to GND on SW_CTL, and add physical pull-up.
Add pull-up on SP_CS3.
Tested, and works ok - pass
Vehicle 9 pin port
Visually ok - pass
Connections ok
Expansion 26 pin port
Visually ok - pass
SPI MOSI/MISO swapped
Connections ok
USB port
Visually ok - pass
To change to a physically stronger port (or mounting arrangement)
Expansion slot #1
Visually ok - pass
Expansion slot #2
Visually ok - pass
To be removed in production board

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:

$ 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

$ espefuse.py -p /dev/tty.SLAB_USBtoUART  summary
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)

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.

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.

Here is what I sent China:

and this is what they sent back:

Touché, China. You win that one.

We’re trying to find some low-profile stacking connectors to keep the depth reasonable.

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.

Regards, Mark.

> On 22 May 2017, at 10:58 AM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
> 
> I'm still trying to work out the stackable/side-by-side issue.
> 
> 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.
> 
> I am thinking that perhaps there is a way out. 
> 
> 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.
> 
> 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).
> 
> Size wise, we could go with something more like an Aurduido Due. Wider than OVMS v2, but about the same height and depth.
> 
> Thoughts?
> 
> Regards, Mark.
> 
> <image1.jpeg>
> 
> <image2.jpeg>
> 
> 
>> On 19 May 2017, at 2:23 PM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
>> 
>> 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.
>> 
>> Both 3G and 4G development expansion boards are also being made now, and I should have those next week.
>> 
>> 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).
>> 
>> 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).
>> 
>> 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.
>> 
>> What do people think?
>> 
>> In the meantime, on with development (now that at last I have a target in my hands).
>> 
>> Mark
>> 
>> <image1.jpeg>
>> 
>> <image2.jpeg>
>> 
>> <image3.jpeg>
>> 
>> <image4.jpeg>
>> 
>> <image5.jpeg>
>> 
>> <image6.jpeg>
>> 
>> <image7.jpeg>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20170609/e2f214d9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image2.jpeg
Type: image/jpeg
Size: 57004 bytes
Desc: not available
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20170609/e2f214d9/attachment-0001.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.tiff
Type: image/tiff
Size: 547550 bytes
Desc: not available
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20170609/e2f214d9/attachment-0001.tiff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 269B1E05-5609-4430-B04B-23D2A314D01E.png
Type: image/png
Size: 20970 bytes
Desc: not available
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20170609/e2f214d9/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 6DBB6579-A139-46BE-8664-2C3B3D74C467.png
Type: image/png
Size: 279402 bytes
Desc: not available
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20170609/e2f214d9/attachment-0003.png>