WROVER and RGB LED

[kolban]

I have connected my WROVER to a Windows 10 PC that is running Oracle's Virtual Box that is running Ubuntu. I have asked Virtual Box to pass through the USB connection (FTDI Dual RS232) through to the Ubuntu guest.

Your suggestion was good ... I powered off my WROVER and attached it to an external USB power pack (no computer). Unfortunately, no change to the symptoms.

All GPIOs = 0, all off
just GPIO 0 on - red/green
just GPIO 2 on - red/green
just GPIO 4 on - blue

Since reports are coming in that others folk's WROVERs are producing the expected outputs, I'm more than prepared to think that "my instance is bad" ... and having no other units to compare against, I have a sample size of 1. As mentioned, I bought it from Adafruit, un-boxed it and pretty much that has been the story. I've run a few different apps on it and tried an OV7670 camera (which I couldn't get to work ... which might be yet another clue). If there are any other diagnostic tests that you would like performed, I'll be delighted to oblige ... and when I've saved a few more pennies, I'll try and buy yet another unit for testing ... in the scheme of all the issues, this isn't huge ... however, I do have an OV7725 camera on order and if THAT won't work with the WROVER and the sample camera software ... then I'll be sad and start to think that my board went bad.

[vardelean]

I'm running the WROVER on Windows 10 with VisualGDB and program the ESP32 directly via JTAG (Jlink).

I do not have the RTS/CTS jumpers on, so most likely RTS should be free from the FTDI chip (one would hope!), but I can't say the same about DTR though. Again, I'm sure the board we have is on a different schematic revision, so I don't know what the connections from DTR and RTS really are on the ESP-WROOM-32 from Adafruit.

But what I do know, is that when the board is powered via the USB, the behavior is identical to the one described by Mr. Kolban.
However, if I remove the USB connector and power via an external 5V adapter, the behavior changes:

IO4 - Blue
IO0 - Red
IO2 - Red

I get RED irrespective of which IO I drive, IO2 or IO0. But if the USB connector is on, both RED and GREEN are on.

The thing that puzzles me the most is that I have declared all 3 IOs as outputs and I set the levels at 0 for the LEDs I don't want turned on. So even if an IO is also connected to the FTDIs RTS/DTR lines through some resistors, I would hope that the ESP32 GPIOs would be able to sink a few mAmps, but that's not the case. When I get the USB turned on and I drive say the GPIO0, I still have some voltage on the GPIO2 (about 1.8V), enough to turn on the mosfet driving the other color. Why do I get 1.8V on a pin that was supposed to be an output in a 0 state? I don't have a good explanation for that, I will have to read the ESP32 documentation, maybe I can find something in the GPIO configuration registers section. Or maybe we can get the proper schematic!

[ESP_Sprite]

I'll see if our documentation team can dig up the latest schematic for the Wrover-Kit boards; that's something that should've happened earlier anyway. Just as a reference: is the silkscreen on your boards red, shiny black or matte black?

[vardelean]

The silk screen is white. The solder mask is flat (matte) black.

As far as I can tell, there is no revision number on either top or bottom silk screen or copper, which is too bad, because there should be one, so that we can all start referring to these boards by numbers as opposed to colors.

[kolban]

Same as Mr Vardelean,
The board text is white and the "background" on the board is matte black.

I'm feeling some what relieved that someone else is seeing strangeness.

[ESP_Sprite]

Fyi, the V3 schematic (for the boards with the matte black finish and the female camera header) can be found here. I'll also add a link to this schematic in the hw docs.

Fwiw:
- Red board, female camera header - v1
- Black shiny board, male camera header - v2
- Black matte board, female camera header - v3

[vardelean]

Interesting choices on the V3 schematic....

It comes down to this: can't have the nRTS and nDTR lines from the FT2232 in HiZ (floating) because the transistors Q2/Q9 will get turned on. To prove this, force the lines to be either low or hi by opening the port that communicates to the FTDI chip (not the JTAG port, just the regular serial port).

Load the program: the LEDs will look wrong.
Open the com port using any terminal you may like: the LEDs will look right.

Proper pin/color mapping:
BLUE GPIO_NUM_4
RED GPIO_NUM_0
GREEN GPIO_NUM_2

[kolban]

Update: I received one of the new (final?) ESP32-WROVER dev kit boards. This has the ESP32-WROVER chip on it.

First question ... what do we "call" this new devboard?

See:
https://www.analoglamb.com/product/esp- ... er-module/

If THIS is the ESP-WROVER-KIT then what of the previous versions with ESP32 (as opposed to ESP32-WROVER)? Will this be THE ESP-WROVER kit and the ones that had just the ESP32 weren't *really* ESP-WROVER-KIT boards? I'm of course fine with that. What I'm hoping to get correct is the story in case questions come up I can give good information.

With that question in front of us, using the ESP-WROVER-KIT (latest available as of 2017/16) which contains the ESP32-WROVER module, the LEDs are finally behaving as I had hoped they would. Red, Green and Blue now light correctly based on the GPIO pin settings with no "multi led" light-ups.

[vardelean]

I suppose that would be "V4"?

[kolban]

I'm not sure ... the way I'm starting to understand the story (and this could be all washed up) ... is that Espressif started with a device called the ESP32. That was delivered (in some cases) in a module called the WROOM. So we have ESP32-WROOM modules.

Then Espressif saw that they were building a 4MByte psRAM chip and said "We can create a new module which contains an ESP32 and a psRAM chip". I think they decided to call that module "WROVER".

Next they said, "We need a rich development kit/board for the new WROVER and we'll call that ESP32-WROVER-DEVKIT". However, at the time of that plan, there was no WROVER module. So instead what they did was create a board **called** ESP32-WROVER-DEVKIT which actually contained an ESP32-WROOM. Now that the WROVER modules actually do exist, the ESP32-WROOM modules are no longer being supplied on the ESP32-WROVER-DEVKIT (which was possibly just a "place holder" anyway), and now we are seeing the existence of ESP32-WROVER-DEVKIT boards with **actual** ESP32-WROVER modules on them ... where an ESP32-WROVER is defined as a module that contains an ESP32 and a 4MByte psRAM chip.

Again ... this is just a possible story ... but its what I'll mentally hold until I hear otherwise.