Troubleshooting (hardware?)

permal
Posts: 384
Joined: Sun May 14, 2017 5:36 pm

Troubleshooting (hardware?)

Postby permal » Thu Oct 11, 2018 7:59 pm

Hi,

Given the following,and the fact that the flash succeeds, what could be the cause for it not detecting flash size and timing out? There is obviously communication between the ESP32 Wrover module and the PC. Also, I can run the monitor and observe the output from the Wrover.
Running esptool.py in directory /home/permal/esp/esp-idf/examples/get-started/hello_world/build
Executing "/usr/bin/python /home/permal/esp/esp-idf/components/esptool_py/esptool/esptool.py -p /dev/ttyUSB1 -b 115200 write_flash @flash_project_args"...
esptool.py -p /dev/ttyUSB1 -b 115200 write_flash --flash_mode dio --flash_size detect --flash_freq 40m 0x1000 bootloader/bootloader.bin 0x8000 partition_table/partition-table.bin 0x10000 hello-world.bin
esptool.py v2.5.1
Serial port /dev/ttyUSB1
Connecting....
Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse
MAC: b4:e6:2d:c9:17:85
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Warning: Could not auto-detect Flash size (FlashID=0x0, SizeID=0x0), defaulting to 4MB
Flash params set to 0x0220
Compressed 22784 bytes to 13490...
Wrote 22784 bytes (13490 compressed) at 0x00001000 in 1.2 seconds (effective 151.9 kbit/s)...

A fatal error occurred: Timed out waiting for packet header
esptool.py failed with exit code 2
An important note is that I'm flashing (via UART) using a Wrover Kit v3 to a Wrover module on a custom PCB. So far only the power supply part and the Wrover itself are mounted on the PCB. Flashing the Wrover module on the kit itself works fine.

The wires that are connected between the kit and the PCB are these:

GND, RX-TX, TX-RX, IO0-GPIO0, nSRST-CH_EN.

I've got a flat cable of ~3dm between the kit and the PCB.

Any thoughts are welcome.

Edit: Seems flashing does not actually succeed. At least, erasing the flash ends in timeout and the program in the chip remains.

Edit2: Is it safe to assume that there a working two-way communication based on the above output? My scope shows me data both ways, but there is some noise on the 1's and 0's, i.e. fluctuating voltage levels by some 100mV, not sure if that can result in these issues.

ESP_Angus
Posts: 2344
Joined: Sun May 08, 2016 4:11 am

Re: Troubleshooting (hardware?)

Postby ESP_Angus » Fri Oct 12, 2018 4:53 am

Serial link itself seems fine, or you'd be seeing connection errors. The all-zero flash IDs suggest that something is shorting out or disabling the flash chip on the target module.

GPIOs 6 - 11 are used for the internal SPI Flash (plus GPIOs 16, 17 for the PSRAM). If any of these are connected to something else, or shorted, then SPI flash communications may fail. (This information can be found in the ESP32-WROVER datasheet section "Peripherals and Sensors".)

permal
Posts: 384
Joined: Sun May 14, 2017 5:36 pm

Re: Troubleshooting (hardware?)

Postby permal » Fri Oct 12, 2018 6:17 am

Thanks Angus,

I was thinking along the same lines. Your statement confirms my line of thought, I'll pursue this further tonight.

permal
Posts: 384
Joined: Sun May 14, 2017 5:36 pm

Re: Troubleshooting (hardware?)

Postby permal » Fri Oct 12, 2018 8:00 pm

Angus (or anyone else), would you please have a look at the following schematic extracts.

This first shows how I have defined my foot print for the ESP32 Wrover, based on this datasheet. At the bottom are IO6-11 plus the not connected pins.

As for GPIO16 and GPIO17, they are not, according to the schematic, actually connected to any external pin on the Wrover module. Unless they are also named RTC_GPIO16 (aka gpio14, pin 14) and RTC_GPIO17(aka gpio27, pin 12), that is at least the only GPIO16/17 I can find in "Table 3: Pin definitions".
footprint_wrover.png
footprint_wrover.png (25.5 KiB) Viewed 5945 times
This second image shows what I've currently put on the PCB. Pins 13, 14, 16, 23 (i.e. JTAG) are connected to a MAX4948, currently powered, but not enabled so it doesn't route them further, though they are also connected to the JTAG-pins on the Wrover Kit v3. U302 (the TXB0102DCU in the lower right is not mounted. [Yes, I've seen the missing control for OE on that chip]). I hope this is readable, cound't get KiCad to output a png and the forum doesn't accept SVG-files.

I was thinking that the strapping pin 14/gpio12/mtdi might be pulled low on the Wrover kit during flash (so the wrong voltage is set), but that can't be since the kit can flash the on-board module.

Strapping pin MTDO for the timing of SDIO Slave, could it cause this? There is a pull up on it to accommodate it for use with the SD Card when not used for the JTAG.
mcu.png
mcu.png (42.95 KiB) Viewed 5945 times

permal
Posts: 384
Joined: Sun May 14, 2017 5:36 pm

Re: Troubleshooting (hardware?)

Postby permal » Sat Oct 13, 2018 11:12 am

New finding: A 10K pull-up to +3.3V on GPIO2 (strapping pin) seems to be the culprit.

The reason for the pull-up to be there is the same as R153 in the Wrover Kit v3. My circuit and the kit's circuit are actually the same, they both both connect SD_DATA0 to GPIO2, as per the pin definitions in the ESP32 datasheet.

It seems I have missed some info regarding the function of this particular strapping pin. The docs actually spells it out pretty clearly. I guess I'll have to solder two wires (and add a jumper in the next version of the PCB) between IO0 and IO2. Hopefully that'll do the trick.

One last thing; R3, (5k) in the Wrover v3 kit, pulls GPIO2 to 1.1V (1/3:rd of 3.3V since R3 and R153 creates a voltage divider), what's the purpose of this resistor when the kit has the extra circuitry to pull GPIO2 low via Q9, controlled by nDTR/nRST? Also, since it pulls two thirds low, doesn't that violate the requirements for the SD-Card?

Edit: A jumper wire between IO0 and IO2 allows flashing to function as expected.

Who is online

Users browsing this forum: Google [Bot] and 82 guests