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@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:
They hard-code the flash CS pin (GPIO10) in the library, so our external CS isn’t going to work.
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@webb-johnson.net <mailto:mark@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@webb-johnson.net <mailto:mark@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@webb-johnson.net <mailto:mark@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:
Change WROOM-32 to WROVER (on circuit antenna version, similar to WROOM-32).
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.
WROVER PSRAM uses IO16 and IO17, so we can’t use that for modem. Move modem to IO4 and IO13.
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?
When burning e-fuses, need to take care with 1.8V/3.3V SDD_SDIO fuse - leave at 1.8V.
Add capacitors for SD CARD and external Flash, as per Espressif example.
Increase size of solder pad for big capacitors, and USB connector, to make it stronger.
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 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3> Commit: 9504df70be78b6626970ec0ea53d2c2470e90afa https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/9504... <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/9504df70be78b6626970ec0ea53d2c2470e90afa> Author: Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>