Just got WROVER dev board but unusable

[liudr]

I just got an esp32-WROVER module and was unable to type anything into its serial repl. It just boots up and lists the content of the sd card and prints Hello World. No ">>>". Here is the boot information besides the green LED flashing at once every 2 seconds:

ets Jun 8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x3b (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:1
load:0x3fff0010,len:4
load:0x3fff0014,len:708
load:0x40078000,len:0
load:0x40078000,len:11460
entry 0x400789f4
Initializing SD card...initialization done.
OVERLAYS/
AKKORD~1.DTB 1130
README 45844
ADAU19~1.DTB 1411
ADS784~1.DTB 2426
BMP085~1.DTB 449
AT86RF~1.DTB 1668
AUDIOI~1.DTB 787
BOOMBE~1.DTB 1023
BOOMBE~2.DTB 783
DHT11~1.DTB 983
DPI24~1.DTB 789
DWC-OT~1.DTB 423
DWC2~1.DTB 908
ENC28J~1.DTB 1403
GPIO-I~1.DTB 1056
GPIO-P~1.DTB 901
HIFIBE~1.DTB 779
HIFIBE~2.DTB 655
HIFIBE~3.DTB 1358
HIFIBE~4.DTB 783
HY28A~1.DTB 2468
HY28B~1.DTB 2939
I2C-GP~1.DTB 819
I2C-MU~1.DTB 2185
I2C-PW~1.DTB 644
I2C-RT~1.DTB 2089
I2C0-B~1.DTB 1182
I2C1-B~1.DTB 854
I2S-GP~1.DTB 343
I2S-MM~1.DTB 263
IQAUDI~1.DTB 1015
IQAUDI~2.DTB 1015
LIRC-R~1.DTB 1348
MCP251~1.DTB 1833
MCP251~2.DTB 1833
MMC~1.DTB 1053
MZ6158~1.DTB 2850
PI3-AC~1.DTB 569
PI3-DI~1.DTB 810
PI3-MI~1.DTB 1097
PISCRE~1.DTB 2713
PISCRE~2.DTB 2617
PITFT2~1.DTB 1544
PITFT2~2.DTB 2385
PITFT2~3.DTB 2802
PPS-GP~1.DTB 967
PWM-2C~1.DTB 1148
PWM~1.DTB 1037
QCA700~1.DTB 1315
RASPID~1.DTB 965
RPI-BA~1.DTB 489
RPI-DA~1.DTB 671
RPI-DI~1.DTB 2524
RPI-FT~1.DTB 462
RPI-PR~1.DTB 771
RPI-SE~1.DTB 893
SDHOST~1.DTB 879
SDIO-1~1.DTB 1682
SDIO~1.DTB 1728
SDTWEA~1.DTB 699
SMI-DE~1.DTB 376
SMI-NA~1.DTB 1508
SMI~1.DTB 981
SPI-GP~1.DTB 666
SPI1-1~1.DTB 1547
SPI1-2~1.DTB 1920
SPI1-3~1.DTB 2293
SPI2-1~1.DTB 1547
SPI2-2~1.DTB 1920
SPI2-3~1.DTB 2293
TINYLC~1.DTB 4878
UART1~1.DTB 980
VC4-KM~1.DTB 2159
VGA666~1.DTB 758
W1-GPI~1.DTB 1215
W1-GPI~2.DTB 1080
WITTYP~1.DTB 1080
BCM270~1.DTB 13328
COPYIN~1.LIN 18693
LICENC~1.BRO 1494
BCM270~4.DTB 14411
BCM270~2.DTB 13065
BCM270~3.DTB 13101
ISSUE.TXT 145
TEST.TXT 28
BCM271~1.DTB 15081
BOOTCODE.BIN 17932
CMDLINE.TXT 113
CONFIG.TXT 1659
FIXUP.DAT 6480
FIXUP_CD.DAT 2509
FIXUP_DB.DAT 9713
FIXUP_X.DAT 9713
KERNEL.IMG 4122560
KERNEL7.IMG 4224096
START.ELF 2743224
START_CD.ELF 615896
START_DB.ELF 4934920
START_X.ELF 3887400
LICENS~1.ORA 18974
SYSTEM~1/
INDEXE~1 76
QRNG_V~1.BRD 73556
Hello world!
Hello world!
Hello world!
done!

I then tried to flash lobo's firmware but esptool.py fails to make a connection.

esptool.py --chip esp32 --port COM5 --baud 921600 --before default_reset --after no_reset write_flash -z --flash_mode dio --flash_freq 40m --flash_size detect 0x1000 bootloader/bootloader.bin 0xf000 phy_init_data.bin 0x10000 MicroPython.bin 0x8000 partitions_mpy.bin
esptool.py v2.1
Connecting........_____....._____....._____....._____....._____....._____....._____....._____....._____....._____

A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header

I tried to flash official esp32 firmware and erase firmware, same error, so it's esptool.py that couldn't connect. I wonder if the board is defective. I bought it here:

https://www.banggood.com/Wemos-TTGO-T8- ... rehouse=CN

But it actually looks like this:
https://www.aliexpress.com/item/TTGO-T8 ... autifyAB=5

[OutoftheBOTS_]

I also have a TTGO dev board. I have found a number of design faults with it that I listed on Lobo's forum under hardware.

The DTR and RTS lines are not connected so the auto boot selection doesn't work, further more there isn't an boot button to select boot mode. What I did was put a jumper wire between GPIO0 and GND on the header then press reset then it will enter boot mode and you can flash the firmware of your choice.

Do also be aware on my board there is pull up resistors missing from the SD interface so it won't work, I had to connect and external SD BOB to use SD card on it.

I also have been to scared to connect a battery and USB at the same time because I can't see a mosfet on the board that disconnect the Bat+ from the LDO in when the USB Vbus+ is connected so I suspect it will short out the 2 if you connect both at the same time.

[liudr]

Bingo! Did the GPIO0 short to gnd trick you described and was able to flash firmware. I had to hold the jumper wire for a few seconds. On my board, I didn't have to do anything else to make it work.

The strange thing is the sd card was working, yes without any pullups (missing resistors like yours), with the stock firmware, because it listed folders and saved some "Hello world" to a file etc. Now it's not working when I have lobo firmware of all_psRAM.

I'll solder on headers and put the dev board on a tiny breadboard. It's amazing that they trimmed down the size of the board about 0.1 inches so there is one hole on either side of the board when it will sit on a breadboard, unlike my other doit.io WROOM board that only has one space on one side of the breadboard. Once I have headers I'll add pullups on the breadboard to see if I can make use of the sd card slot.

[liudr]

Just an unrelated question: is the processor using 16-bit segment register:16-bit pointer for memory spaces? The values of memory locations in the boot messages are awfully large:

D (1781) heap_init: New heap initialised at 0x4009aa50

This translates into 1074375248. That's a bit more than 1Gig. If I do the x86 trick: 0x40090+0xaa50=0x4aae0 about 300K.

[OutoftheBOTS_]

listed folders and saved some "Hello world" to a file etc.

Did this save to the SD card or to the flash ??

My board won't initialize the SD slot built in to the board but will initialize/read/write to an external 1 connected to the header.

[pythoncoder]

Just an unrelated question: is the processor using 16-bit segment register:16-bit pointer for memory spaces? The values of memory locations in the boot messages are awfully large:

D (1781) heap_init: New heap initialised at 0x4009aa50

This translates into 1074375248. That's a bit more than 1Gig. If I do the x86 trick: 0x40090+0xaa50=0x4aae0 about 300K.

The ESP32 is, as the name suggests, a 32 bit processor. 0x4009aa50 is a 32 bit address which is the location of the heap. This has no relation to its size.

The "X86 trick" goes back to the Intel 8086 nearly 40 years ago. It was a way to expand the address space of a 16 bit processor to 20 bits and has no relevance to anything remotely modern

[liudr]

listed folders and saved some "Hello world" to a file etc.

Did this save to the SD card or to the flash ??

My board won't initialize the SD slot built in to the board but will initialize/read/write to an external 1 connected to the header.

It was the SD card. I just checked and there were about 2 dozens of Hello World meaning I've restarted the board while it was running the stock micropython for that many times. I really wish I knew the sd card settings in the stock firmware. Is it possible that somehow the pins' internal pullup resistors were enabled in that firmware?

[liudr]

Yeah, probably started from 8080 when 16-bit memory became insufficient. Apple][/6502 had the paging things so you could change map different memories to the same memory address by changing the page number. Guess staying in 16-bit was a bad idea. The new 386 and above simply revamped the x86 memory pointer mechanism and the segment register became an index on a table, where real memory location is stored and then the real memory is reorganized into guess what pages again and a big table points to where each 4K of memory address really is in actual memory. If the memory doesn't exist, a #page fault interrupt is triggered and the OS swaps memory with swap file. Good old days of 386.

[OutoftheBOTS_]

I really wish I knew the sd card settings in the stock firmware. Is it possible that somehow the pins' internal pullup resistors were enabled in that firmware?

I spent the day playing with the SD card and the 3 modes (SPI, 1_LINE and 4_LINE)

I have found that all the problems come from the fact that the internal pull-ups aren't being engaged in 1_LINE or 4_LINE but are working correctly in SPI. That's why on the TTGO boards that don't have external pull-up's can only use SPI mode to access the SD card.

The work around that I found was to setup each needed pin as a input pullup pin before mounting the SD card in 1_LINE or 4_LINE mode see my post on LoBo forum https://loboris.eu/forum/Thread-Found-t ... in-SD-card

I am not sure if it is a bug in LoBo firmware or a bug in the underlying esp-idf

[liudr]

Thanks. I can confirm that manually enabling the pull ups works on my TTGO board but only the SPI mode. The other two modes don't work. I think you got a duplicate pin 15 command. I will try further. Having sd card working without BOB is great!