ESP32-WROOM-32

I got myself a backup HDMI to VGA adaptor (so I have a spare) and also picked up a cheap clone of a DOIT ESP-32 board, just to play around with.

The board has a daughterboard with a big metal can marked ESP32-WROOM-32, plus a USB interface and two LEDs.

Plugging it in shows a red LED light up, and after installing the serial drivers (and discovering that the serial device and my WiFi dongle installed at the same time will freeze XP – so the PC is currently plugged into the switch and sharing the Vonets), I got HyperTerminal receiving data:

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:5564
load:0x40078000,len:0
load:0x40078000,len:13756
entry 0x40078fb4
I (28) boot: ESP-IDF v3.0.1 2nd stage bootloader
I (29) boot: compile time 05:26:56
I (29) boot: Enabling RNG early entropy source...
I (33) boot: SPI Speed      : 40MHz
I (37) boot: SPI Mode       : DIO
I (41) boot: SPI Flash Size : 4MB
I (45) boot: Partition Table:
I (49) boot: ## Label            Usage          Type ST Offset   Length
I (56) boot:  0 phy_init         RF data          01 01 0000f000 00001000
I (64) boot:  1 otadata          OTA data         01 00 00010000 00002000
I (71) boot:  2 nvs              WiFi data        01 02 00012000 0000e000
I (79) boot:  3 at_customize     unknown          40 00 00020000 000e0000
I (86) boot:  4 ota_0            OTA app          00 10 00100000 00180000
I (93) boot:  5 ota_1            OTA app          00 11 00280000 00180000
I (101) boot: End of partition table
I (105) boot: No factory image, trying OTA 0
I (110) esp_image: segment 0: paddr=0x00100020 vaddr=0x3f400020 size=0x1fe00 (13
0560) map
I (165) esp_image: segment 1: paddr=0x0011fe28 vaddr=0x3ffc0000 size=0x001e8 (
 488) load
I (165) esp_image: segment 2: paddr=0x00120018 vaddr=0x400d0018 size=0xddcc0 (90
8480) map
I (490) esp_image: segment 3: paddr=0x001fdce0 vaddr=0x3ffc01e8 size=0x03010 ( 1
2304) load
I (495) esp_image: segment 4: paddr=0x00200cf8 vaddr=0x40080000 size=0x00400 (
1024) load
I (497) esp_image: segment 5: paddr=0x00201100 vaddr=0x40080400 size=0x0eba0 ( 6
0320) load
I (530) esp_image: segment 6: paddr=0x0020fca8 vaddr=0x400c0000 size=0x00064 (
 100) load
I (540) boot: Loaded app from partition at offset 0x100000
I (540) boot: Disabling RNG early entropy source...
Bin version(Wroom32):1.1.1
I (658) wifi: wifi firmware version: bffcf7f
I (659) wifi: config NVS flash: enabled
I (659) wifi: config nano formating: disabled
I (668) wifi: Init dynamic tx buffer num: 32
I (669) wifi: Init data frame dynamic rx buffer num: 32
I (669) wifi: Init management frame dynamic rx buffer num: 32
I (675) wifi: wifi driver task: 3ffdf604, prio:23, stack:4096
I (680) wifi: Init static rx buffer num: 10
I (683) wifi: Init dynamic rx buffer num: 32
I (688) wifi: wifi power manager task: 0x3ffe3ce4 prio: 21 tack: 2560
I (721) wifi: mode : softAP (cc:50:e3:8b:ac:ad)
I (728) wifi: mode : sta (cc:50:e3:8b:ac:ac) + softAP (cc:50:e3:8b:ac:ad)
I (732) wifi: mode : softAP (cc:50:e3:8b:ac:ad)

That is all the boot log says.

My phone can connect to the device (SSID “ESP_8BACAD”) and is allocated IP address 192.168.4.2 (channel 1, 48Mbps, with an IPv6 address too), with 192.168.4.1 as the AP. However there is nothing responding at that IP address. No webserver, nothing. I scanned ports 0-10240 and nothing is open. Doesn’t respond to pings either. Is this normal or is something wrong with mine?

Serial port, no reply to anything. Tried Lua (“node.restart();” etc) and also various AT commands.

Installed the Arduino IDE on my XP box. Clunky thing, takes forever to do anything. But, alas, it fails. Some sort of Python error, but given I know nothing about Python…

Tried to flash in new firmware in case that was the problem, but the flash tool (says “for Windows”) is flagged as being an invalid executable. It’s probably 64 bit or something. :-/

There’s apparently a way to push firmware via serial (boot while holding the boot button), but I’ve not found any info on how that works.

Any ideas?

Installed Python 2.7 (works with XP), installed numerous versions of PySerial until I found one that works with XP, and then (after removing esptool.exe) ran the esptool.py code.

It’s finickety, but it works. Need to fiddle with the boot buttons to get it to connect. ESP32D0WDQ6 at 240MHz. Took a copy of the current firmware (I think?), using:

esptool.py -p COM5 read_flash 0 0x400000 flashfile.bin

Now to see if there’s a way to use esptool to write something. I keep finding Lua for the older 8266 (8622? the previous one), and the factory firmware is in many parts so I’m not sure if I need them all or just pick the one I want…?

Update1: Bit the bullet and reflashed the factory firmware. Same behaviour as before. I can see my phone connecting on the serial tracing, but… if there’s no HTTP port and no way to talk to the device, how the hell do you get it to connect to YOUR network?

Update2: Found an example to install the AT processor firmware in a Debian manpage. ;-) Renamed the directories to mean less typing.
This is the command, and I’ll copy it here in case I need it later…

esptool.py -p COM5 write_flash 0x1000 bl/bootloader.bin 0x20000 at_customize.bin 0x21000
cp/ble_data.bin 0x24000 cp/server_cert.bin 0x26000 cp/server_key.bin 0x28000 cp/server_ca.bin
0x2A000 cp/client_cert.bin 0x2C000 cp/client_key.bin 0x2E000 cp/client_ca.bin oxF000
phy_init_data.bin ox100000 esp-at.bin 0x8000 partitions_at.bin

(it’s all one line – phew!)

Update3: Didn’t work, so I erased the flash (panic reboot reboot reboot ;-) ) and try again…

Update4: Didn’t work. Exactly the same stuff as the top of the screen. Correction, it’s firmware v1.1.2. But still doesn’t do anything other than lets a device connect/disconnect. I’m stumped now.

Success!

Sort of. :-)

I gave up on the standard firmware. AT simply didn’t want to work. As for the rest, I’m starting to suspect that it may be a base OS with nothing on top of it, which is a bit weird given that it works as an AP?

Tried a different approach…

esptool.py -p COM5 write_flash 0x1000 bootloader.bin 0x10000 lua_rtos.bin 0x8000 partitions_singleapp.bin

And, lo!

/ > ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
[...snip...]
I (101) boot: Partition Table:
I (113) boot: ## Label            Usage          Type ST Offset   Length
I (135) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (159) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (182) boot:  2 factory          factory app      00 00 00010000 00100000
I (205) boot: End of partition table
I (218) boot: Disabling RNG early entropy source...
I (235) boot: Loading app partition at offset 00010000
[...snip...]
I (1636) heap_alloc_caps: Initializing. RAM available for dynamic allocation:
I (1658) heap_alloc_caps: At 3FFBE128 len 00021ED8 (135 KiB): DRAM
I (1679) heap_alloc_caps: At 3FFE8000 len 00018000 (96 KiB): D/IRAM
I (1700) heap_alloc_caps: At 4009E408 len 00001BF8 (6 KiB): IRAM
I (1721) cpu_start: Pro cpu up.
I (1733) cpu_start: Starting app cpu, entry point is 0x40080e18
I (0) cpu_start: App cpu up.
I (1764) cpu_start: Pro cpu start user code
I (1821) cpu_start: Starting scheduler on PRO CPU.
I (72) cpu_start: Starting scheduler on APP CPU.

--------------------
Booting Lua RTOS...

 Boot reason: Vbat power on reset
Time not set: build time: Wed Mar 15 16:30:19 2017

  /\       /\
 /  \_____/  \
/_____________\
W H I T E C A T

Lua RTOS LoBo 0.2 build 1489595419 Copyright (C) 2015 - 2017 whitecatboard.org
board type ESP32 THING
cpu ESP32 rev 1 at 240 Mhz
flash EUI 5059821224a26258
spiffs0 start address at 0x180000, size 1024 Kb
spiffs0 mounted
Mounting SD Card: Failed to initialize. Check connection.

can't redirect console messages to file system, an SDCARD is needed

Lua RTOS LoBo 0.2 powered by Lua 5.3.4

Executing /autorun.lua ...
I (371) phy: phy_version: 329, Feb 22 2017, 15:58:07, 0, 0
SYSTEM_EVENT_STA_START
SYSTEM_EVENT_STA_DISCONNECTED
SYSTEM_EVENT_STA_CONNECTED
SYSTEM_EVENT_STA_GOT_IP

/ >

My autorun simply does dofile("startnet"), and…

…startnet is this. Turns out, by the way, that there’s a simple full screen editor built in. :-)

-- switch on shell so we can give OS commands at the Lua prompt
os.shell(true)

-- Connect to the Livebox
-- (use net.wf.scan() to read APs)
net.wf.setup(net.wf.mode.STA, "Livebox-XXXX", "BigLongPasswordHere")
net.wf.start()

-- get the current time (but read it how?)
net.service.sntp.start()

-- switch on blue LED to indicate the system is up
-- (probably ought to error check stuff, but it'll bomb out early if problem)
pio.pin.setdir(pio.OUTPUT, pio.GPIO2)
pio.pin.sethigh(pio.GPIO2)

So now it connects to my Livebox and turns on its blue LED. I can give it commands, but pretty much any typo throws a kernel panic… Typing os.commscomms() (I made that up) will tell me there’s a Guru Mediation Error of type LoadProhibited occurred on core 0, with a register dump and backtrace. The backtrace is even more gibberish than the stuff CLib spits out. ;-)

Still, it responds now. That’s something.

Colin – if you’re reading this, can you tell me if there’s a way that I can open a serial connection to the ESP32 without touching the RTS pin?

The device is a Silicon Labs CP210x USB to UART Bridge Controller Port 1 (ID 10C4:EA60) and it is recognised by the SerialUSB module.

Using the default !SerialTerminal program, the ports are opened with “#noblock;sleep;nohandshake;baud=115200;data=8;stop=1;noparity” which is exactly right for communicating with the ESP32 except for the fact that the driver appears to assert the RTS pin (even when told not to use handshaking).
This is a problem, for the RTS pin is connected to the system reset line (it’s how the flash uploader forces a reboot after doing its thing).

Which means that at the moment I can connect to the ESP32, read all of the buffered data from the system boot, and then crash out with a device not found error because… yeah… RTS caused a reboot. ;-)

This is a problem, for the RTS pin is connected to the system reset line (it’s how the flash uploader forces a reboot after doing its thing).

Sounds like the board software expects to do software handshake with the terminal but the terminal expects a hardware handshake.
Normal practice there is to do things looping signals back to the bit expecting the hardware handshake.

No, the board actually uses RTS to drive the reset logic.
https://github.com/espressif/esptool/wiki/ESP32-Boot-Mode-Selection#user-content-automatic-bootloader

If RTS is wired directly to EN then RTS/CTS “hardware flow control” needs to be disabled in the serial program to avoid this.

Or have the terminal RTS and CTS linked to each other and not to the board.

There’s also this:

Development boards (including all Espressif boards) usually use additional circuitry to avoid this problem – if both RTS and DTR are both asserted together, this doesn’t reset the chip. Consult Espressif development board schematics for the specific details.

Bottom left of schematic

Or have the terminal RTS and CTS linked to each other and not to the board.

Somewhat hard to achieve, given the serial wire is maybe a couple of centimetres long. The input is USB, the square lump is a USB to serial interface, and the serial data is routed to the SoC. There’s no flow control in the traditional sense (rather like ARM boards), it just so happens that the serial interface does support those pins and…they’re being used for something entirely different.

Bottom left of schematic

Clearly it’s not working so either (unlikely option) SerialUSB doesn’t asset RTS and DTR together or (likely option) my clone board didn’t bother to implement this. You can tell which way I’m thinking. ;-)

I hope there’s a way to do it using SerialUSB. I mean, RISC OS doesn’t want to be bested by HyperTerm now, does it?!?

What’s going on? I have a couple of esp32 boards. Besides the Micro Usb port coming off both of them, I found them easy to put Lua and Arduino stuff on.
I think sometimes I had to mash the reset button at the right time but that’s about it.

I take it you saw SpriteTM’s Doom demo running on a higher end one? They also have Tiny Basic (IIRC) baked in.

Back to topic. I’ve found Arduino great for returning scrambled microcontroller to operational. Reflash with whatever after.

Do you have a link to the board?

I hope there’s a way to do it using SerialUSB.

Have you tried OS_Args 9. The serial spec is here – I wonder why it has been retired to the attic.

Have you tried OS_Args 9.

Yes, but no dice. OS_Args 9 works on a file handle, by which point RTS has already been fiddled. It’s either the OPENIN or the OPENOUT that’s doing it.

Do you have a link to the board?

https://www.amazon.fr/gp/aw/d/B071JR9WS9

What’s going on?

I’m using XP so… the Arduino IDE appears to work but it’s slow. The ESP32 additions don’t. The compiled tools refer to functions not present in the API, though it appears to also need python anyway but forgot to mention that. Version 2.7 as well, installed to root folder. And it needs PySerial too, a version of enough not to use CancelIoEx. And then, if one is lucky, it’s possible to talk to the device via command line. I don’t know yet if the IDE build works.

They also have Tiny Basic (IIRC) baked in.

I tossed the factory firmware to the Pi and looked at it in Zap. It appears to be nothing but the base RTOS. Not sure why softAP starts when there’s nothing it can do, but there you go. I wanted to run Lua to have it do something functional. Later on I’ll have another crack at using the IDE, I’m familiar with C. The Lua I used was copy pasted from websites.

Oh, and all of the other tools I’ve found do not work on XP. They say “for Windows” with no indication of what version or if 32/64 bit.
The general advice on the internet seems to be “it works on Linux”…

What about DeviceFS_CallDevice 14 the drivers IOCTL entry point I think you can call that just using the serial device name just like WakeupRX can be called in the EtherUSB upcall handler – though its years since I tested it.

When the port is opened, does the driver do anything like set the control lines to a known (safe) state? It’s the act of opening the device as a file that is affecting the RTS line.

Yes I set DTR and RTS. I can knock up a version with a ‘rtsdtr=n’ option in the filing system special fields for you to try if you like. bit 0 of n would be dtr and bit 1 would be rts. The options would set the initial values of DTR RTS.

SerialUSB_rtsdtr.zip – untested

Thank you for that.

Just to confirm, I’d open the port with special fields “#noblocking;nohandshake;rtsdtr=x;baud=115200;data=8;stop=1;noparity:”?

If that is correct, then I’ve tried values 0, 1, 2, and 3 (ensuring device has started each time). I think 0 and 2 hold the device in reset (needs to be power cycled), while the others cause the previous behaviour of the device restarting.

Would it be possible to make a “noctrl” version that just doesn’t touch any of the control lines at all? It seems to boot up from cold in a suitable mode, so see if that works (and hope the controller chip isn’t pedantic and expects CTS or something).

BTW, I was using the SerialTerminal written in BASIC. The one in C causes an instant hard reboot. No idea why – it’s not the ESP32 taking too much power, it does likewise when the ESP32 isn’t connected! :-)

SerialUSB_noctrl.zip. Which serial device does it use?

I tossed the factory firmware to the Pi and looked at it in Zap. It appears to be nothing but the base RTOS

You won’t find it in there. It really is baked in. Can’t remember the details but IIRC if a certain pin is twiddled or booting totally fails the esp drops through to it.

I have the ESP32 hooked up to the PC at the mo… I’ll try this later on.

The device, as mentioned above, is: Silicon Labs CP210x USB to UART Bridge Controller Port 1 (ID 10C4:EA60)

Working on the H3, I was using USBSerial and !Connector. Works well.

As always, forgot why I came here. I dug out an esp32 board just now. I only have a pinebook and the “photo frame” pi at my disposal but maybe I can help somehow?

I see you have the onboard USB-Serial device, My older ESP8266 still uses the same method for controlling bootloading options (followed the link) so control line progammability could be used for the whole series. The external USB-Serial convertor would have to be control line capable then, and if you develop for the CP210, it might have to be that driver as well.

I’m going to have to ditch the Lobo build of LuaRTOS – it crashes the board when trying to turn on the http service. Useful…

I have picked up the original LuaRTOS firmware bits (not the Lobo build) to consider.

I’ve reinstalled the default firmware, and added the AT firmware (which doesn’t work). I’m currently compiling an LED flasher using the Arduino IDE. It is unbelievably slow, which isn’t helpful as I’m progressively hacking the platform.txt file to run the Python scripts instead of the non-functional precompiled binaries. Oh, it actually compiled this time. That’s a first. Let’s see if it can upload…

Oh YES! It’s stupid and tiny, but my blue LED is gently pulsing. Finally got that build rubbish pointing to all the right things.

Before I grafted USB cables on to my ESP32s I was just using a USB to 3v3 serial adapter on the broken out header pins. I think I was doing it by releasing reset after starting the handshake on the PC side.

Oops I was too slow. Yes the esp Arduino toolchain are sloooooow. Still useful for messing with things or doing quick hacks though.