Michael,

3. Will v3.3 automatically be built using the latest ESP32 WROVER, i.e. with the revision 3 ESP32 including the hardware SPIRAM fix?

They normally build each batch with the latest. I haven’t checked for a while, so will check one from the last batch I received, and let you know. We can request this, but it will depend on stock.

Down the rabbit hole of detecting chip revision…

I checked a sample from the latest batch, and get:

OVMS:
OVMS WIFI BLE BT cores=2 rev=ESP32/1

Esptool flash_id:
Detecting chip type... ESP32
Chip is ESP32D0WDQ5 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
Device: 4018
Detected flash size: 16MB

Boot log:
I (925) psram: This chip is ESP32-D0WD
I (925) spiram: Found 64MBit SPI RAM device
I (925) spiram: SPI RAM mode: flash 40m sram 40m
I (928) spiram: PSRAM initialized, cache is in low/high (2-core) mode.

I suspect that our old IDF is not detecting the latest revision (because it was released after our firmware).

The raw espfuse command on an old module shows:

CHIP_VER_REV1          Silicon Revision 1                                = 1 R/W (0x1)
CHIP_VER_REV2          Silicon Revision 2                                = 0 R/W (0x0)
CHIP_VERSION           Reserved for future chip versions                 = 0 R/W (0x0)
CHIP_PACKAGE           Chip package identifier                           = 0 R/W (0x0)

Running against the sample from the latest batch shows:

CHIP_VER_REV1          Silicon Revision 1                                = 1 R/W (0x1)
CHIP_VER_REV2          Silicon Revision 2                                = 0 R/W (0x0)
CHIP_VERSION           Reserved for future chip versions                 = 2 R/W (0x2)
CHIP_PACKAGE           Chip package identifier                           = 1 R/W (0x1)

BLK0: 00000000 2a6cbad0 0074a803 0000a200 00001231 00000000 00000004

Using the latest IDF espefuse v3.1, against the sample from the latest batch shows:

CHIP_VER_REV1 (BLOCK0):                  Silicon Revision 1                                 = True R/W (0b1)
CHIP_VER_REV2 (BLOCK0):                  Silicon Revision 2                                 = False R/W (0b0)
CHIP_VERSION (BLOCK0):                   Reserved for future chip versions                  = 2 R/W (0b10)
CHIP_PACKAGE (BLOCK0):                   Chip package identifier                            = 1 R/W (0b001)
MAC_VERSION (BLOCK3):                    Version of the MAC field                           = 0 R/W (0x00)

BLOCK0          (                ) [0 ] read_regs: 00000000 2a6cbad0 0074a803 0000a200 00001231 00000000 00000004

So, I guess it is still rev 1, but it seems a different rev 1 than the older modules? I’m confused….

I’ll check with the supplier and ask for him to try to source rev 3 in future. However, it seems we are going to have to bite the bullet at some point and undertake the massive task of moving to the latest IDF to take advantage of everything they’ve improved in the past couple of years.

Regards, Mark.

On 17 Aug 2021, at 3:55 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

Signed PGP part
Michael,

1. I had the impression we've had more than expected "modem not/stopped working" issues. Is that impression wrong, or didn't those cases share a hardware cause? I was wondering if that could be related to a voltage regulator issue (e.g. https://www.openvehicles.com/node/2855).

I have had just three reports of modem module not working at 12V, but working at 5V. On two, the issue was the power regulator chip blown on the modem board. I don’t think there is anything inherently wrong there - probably just a faulty component or power surge.


2. Any chance to fix the missing HW flow control on the modem UART connection?

I don’t think we have enough GPIOs. Perhaps later when/if ESP32 S3 becomes suitable?

3. Will v3.3 automatically be built using the latest ESP32 WROVER, i.e. with the revision 3 ESP32 including the hardware SPIRAM fix?

They normally build each batch with the latest. I haven’t checked for a while, so will check one from the last batch I received, and let you know. We can request this, but it will depend on stock.

Regards, Mark.

On 17 Aug 2021, at 3:31 PM, Michael Balzer <dexter@expeedo.de> wrote:

Signed PGP part
Mark,

1. I had the impression we've had more than expected "modem not/stopped working" issues. Is that impression wrong, or didn't those cases share a hardware cause? I was wondering if that could be related to a voltage regulator issue (e.g. https://www.openvehicles.com/node/2855).

2. Any chance to fix the missing HW flow control on the modem UART connection?

3. Will v3.3 automatically be built using the latest ESP32 WROVER, i.e. with the revision 3 ESP32 including the hardware SPIRAM fix?

Regards,
Michael


Am 17.08.21 um 07:30 schrieb Mark Webb-Johnson:
For the 4G modem options we need to go through FCC, CE, and ROHS certification. Minimising/eliminating the changes to the main board simplifies this (and brings down the exorbitant costs) but if there is anything urgent / necessary, now is the time to do it.

The goal here is to maintain 100% compatibility with existing OVMS main boards, to keep this is a simple and relatively cheap upgrade of the modem board.

So far, I have come up with this minimal list:

  1. Main board v3.3: Improve soldering of micro USB port. Bigger solder pads, and more solder to secure it better.

  2. Modem board v1.3: Add support for SIM7600 module.

  3. Modem board v1.3: Fix support for DTR sleep/awake support.

Is there anything else required for this update?

Regards, Mark.

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