[Ovmsdev] OVMS Hardware v3.1

Michael Balzer dexter at expeedo.de
Tue Jan 30 17:35:32 HKT 2018 

:-/

I guess that's the price to pay for using bananaware cutting edge technology.

On the plus side, maybe the ESD shield of the WROVER module will help in CE/FCC certification…

Thanks for not losing faith.

Michael


Am 30.01.2018 um 09:33 schrieb Mark Webb-Johnson:
>
> A lot of back-and-forth with China (suppliers, partner, etc).
>
> Bottom line is that we don’t think Espressif is ready for PSRAM + external flash. The IDF code just doesn’t seem to support it. Very frustrating, given that
> nobody on their support forums or issue tracker is saying that; but looking at the code it is pretty obvious they have just tested it with their particular
> use case (this specific set of bus speeds, this particular PSRAM part, etc).
>
> We’re all getting pretty fed up with this. Trying to get Espressif to recognise (and fix) the SD CARD issue took months. Now, we have to go through the same
> hoops for this...
>
> So, we’ve decided to raise the white flag, swallow the extra cost (probably only perhaps US$3 or so, although one-time CE/FCC certification fees could be
> drastically higher), and source a WROVER module with 16MB flash + PSRAM directly in the module. We’re 99% certain that will work, as that is pretty much
> Espressif’s supported configuration. Circuit leads are short, everything is encased in a metal ESD shield, the 1.8v is a non-issue, etc. Lead time for those
> components is 7-to-30 days, so as a quick confirmation we are getting the parts and will modify some of our own WROVER modules first (remove the top, unsolder
> the 4MB flash, solder in a replacement 16MB flash). Time to dust off the microscope again.
>
> Flash chips are being overnighted to me, and both China and HK sides are doing the work at the same time. We should have confirmation within this week. The
> peripherals all seem ok with the new board, so it is only the 16MB flash issue to resolve.
>
> Regards, Mark.
>
>> On 30 Jan 2018, at 9:00 AM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>>
>>
>> News: Some good, some bad.
>>
>> Injection moulded cases are here. They look good, feel good, and everything fits. Blue light doesn’t show through (we should turn it off to save power
>> anyway). Our logo looks particularly good as part of the mould.
>>
>> All the peripheral functionality seems to work just fine. SD CARD, CAN bus, simcom, USB flashing, GPIOs, EGPIOs, etc.
>>
>> But the bad news is external flash + psram combo is not working well. Just seems flaky. I tried ‘scoping the level converter last night, and the signal
>> looked really dirty. We’re not sure if the problem is the level converter propagation delay (we’re right on the borderline with that) or trace layout (we
>> moved the flash to the underside of the board to get it closer to the ESP32 module, but that meant using vias which could be contributing to the issue). We
>> have found some alternative level converters which bring propagation down to 1.3ns or so and are supposedly good for up to 100Mhz, and we’re trying to
>> hand-modify a board at the moment to see if those improve things. I dug some into the ESP32 PSRAM library and it is really strange:
>>
>>  1. They hard-code the flash CS pin (GPIO10) in the library, so our external CS isn’t going to work.
>>
>> 2.
>>     They have a separate clock for PSRAM, and for some reason want to delay it with respect to the flash clock. They do this by routing it in and out through
>>     an internal GPIO that is not externally visible (and that pass through the GPIO matrix delays it). Path ends up SPI CLK --> GPIO28 --> signal224(in then
>>     out) --> internal GPIO29 --> signal225(in then out) --> GPIO17(PSRAM CLK). Urgh.
>>
>>
>> I’m trying to fix this at the firmware level, but I suspect that it is not going to be trivial.
>>
>> Regards, Mark.
>>
>> <PastedGraphic-5.tiff><PastedGraphic-6.tiff>
>>
>>> On 26 Jan 2018, at 2:01 PM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>>>
>>> 3.1:
>>>
>>> <A3D70FF6-1425-4220-9FC2-4D25EF2EB4A0.png>
>>>
>>> <latest.gif>
>>>
>>> Mark
>>>
>>>
>>>> On 26 Jan 2018, at 10:44 AM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>>>>
>>>> Version 3.0 main board:
>>>> <49304d73$1$15e08a5e24c$Coremail$guangzhouxinghai$163.com <http://163.com/>>
>>>>
>>>>
>>>> Version 3.1 main board:
>>>> <C1BAC905-8C0F-4A15-A50D-E74D649A94FA.png>
>>>> <6D8998ED-A8F1-494D-BA01-2D4A4990DF1E.png>
>>>>
>>>> We’ve just started testing it now.
>>>>
>>>> Regards, Mark.
>>>>
>>>>> On 10 Jan 2018, at 2:41 PM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>>>>>
>>>>>
>>>>> Production…
>>>>>
>>>>> Analog Lamb, while interesting, is just (a) too expensive (double the price), (b) unproven, (c) uncertified, and (d) has long lead times. Using proven
>>>>> Espressif certified modules seems the safer way to go.
>>>>>
>>>>> So, we’ve decided to go with a switch to a standard certified ESP WROVER module, and external 16MB flash memory. The circuit board footprint for this is a
>>>>> little larger than the WROOM-32 module we’ve been using, and requires one more 3.3V->1.8V power conversion, but seems the safest way to go.
>>>>>
>>>>> Accordingly, I’ve agreed with the China guys to proceed along these lines for the main board:
>>>>>
>>>>>  1. Change WROOM-32 to WROVER (on circuit antenna version, similar to WROOM-32).
>>>>>
>>>>>  2. We can free IO12 (SD_D2), IO13 (SD_D3), and IO4 (SD_D1), by using just 1-line SDCARD. I don’t really want to use IO12 as that is a bootstrapping pin.
>>>>>
>>>>>  3. WROVER PSRAM uses IO16 and IO17, so we can’t use that for modem.
>>>>>       * Move modem to IO4 and IO13.
>>>>>
>>>>>  4. Change to 1.8V 16MB flash chip (W25Q128FW?). As SDD_VDIO is not exposed, add a simple regulator 3.3V->1.8V for external flash?
>>>>>
>>>>>  5. When burning e-fuses, need to take care with 1.8V/3.3V SDD_SDIO fuse - leave at 1.8V.
>>>>>
>>>>>  6. Add capacitors for SD CARD and external Flash, as per Espressif example.
>>>>>
>>>>>  7. Increase size of solder pad for big capacitors, and USB connector, to make it stronger.
>>>>>
>>>>>  8. For the data lines of circuit traces SDCARD, SPI bus, external flash, take care to keep away from power traces or other sources of interference and
>>>>>     keep the traces as short as possible.
>>>>>
>>>>>
>>>>> The change to WROVER is a PITA at this stage, but that 4MB PSRAM should give us more headroom and the extra bill-of-materials costs is just a couple of US$.
>>>>>
>>>>> For the modem, we’re double-checking the power (which seems ok, but check to be sure), and changing passive -> active antenna. At the moment, it seems to
>>>>> be just a couple of passive components soldered inline between two easily accessible points. For existing developer modems in the field, we’ll try to make
>>>>> a simple upgrade kit (passive->active) for GPS, and post them out. If you don’t need GPS (such as Roadster users), the modem boards are functionally the
>>>>> same as the production ones.
>>>>>
>>>>>     <A04F19CE-27D9-439A-89DB-8B70136598A0.png>
>>>>>
>>>>>
>>>>> Existing developer OVMS v3 boards (with WROOM-32 module) will continue to be called v3.0. New production OVMS v3 boards (with WROVER module) will be
>>>>> called v3.1. We have conditional compilation in the firmware, to switch the pin assignments and whatever else is required.
>>>>>
>>>>>      Branch: refs/heads/for-v3.0
>>>>>      Home:   https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3
>>>>>      Commit: 9504df70be78b6626970ec0ea53d2c2470e90afa
>>>>>          https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/9504df70be78b6626970ec0ea53d2c2470e90afa
>>>>>      Author: Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>>
>>>>>      Date:   2018-01-10 (Wed, 10 Jan 2018)
>>>>>
>>>>>      Changed paths:
>>>>>        M vehicle/OVMS.V3/main/Kconfig
>>>>>        M vehicle/OVMS.V3/main/ovms_peripherals.h
>>>>>
>>>>>      Log Message:
>>>>>      -----------
>>>>>      Support for OVMS hardware v3.1
>>>>>
>>>>>
>>>>> Converting developer v3.0 boards to v3.1 is not really feasible (a skilled solderer could probably use a 16MB Analog Lamb WROOM-32+PSRAM module; that
>>>>> would be a relatively simple de-solder + re-solder of the module, a not-so-simple re-arrange of the traces for IO16->IO4 and IO17->IO13, and disabling of
>>>>> external 16MB flash). Anyway, those existing developer modules should be fine to continue to use (just without the extra PSRAM).
>>>>>
>>>>> We are today finalising the circuit schematic and board layout for the above, and building a couple of test boards (with WROVER modules). I should have
>>>>> one in about a week’s time (assuming all the components are available). In that time, we’ll finish the ESP IDF v3.0 support, and test late next week /
>>>>> over next weekend (20th/21st Jan). Assuming no problems, we should be able to give factory the go-ahead to produce early the week after.
>>>>>
>>>>> Given that timing, I doubt if we are going to be able to get these boards made before the Chinese New Year holidays. Even if we can get them made,
>>>>> FastTech distribution may not be able to get them out during the holidays. Manufacturing in China starts to close down around the end of January / early
>>>>> February this year. New Year itself is mid-February. Anyway, we’ll get this all finalised, payment and instruction to start manufacturing in place, then
>>>>> do the best we can and get these out available during February. A big warning is going to go with them that this is for early adopters only, and firmware
>>>>> is changing on a daily basis. Updating firmware via wifi / sd card should be fine.
>>>>>
>>>>> I’m seeing a light at the end of a long dark tunnel.
>>>>>
>>>>> Regards, Mark.
>>>>>
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.teslaclub.hk <mailto: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

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20180130/e3a79ab7/attachment-0001.html>

More information about the OvmsDev mailing list