wroom32 schematics
wroom32 schematics
I just received wroom32 from Olimex
I am trying to design minimalistic custom board that would allow flashing without reset and flash buttons. I tried to follow following instructions https://gist.github.com/morganrallen/09 ... 9c2a621d50
I plan to flash upload firmware with usb to ttl serial from ebay like here:
http://www.ebay.com/itm/381292739186?_t ... EBIDX%3AIT
@morganrallen is connecting this pins dtr and rts directly but devc from espressif (https://dl.espressif.com/dl/schematics/ ... V2_sch.pdf) is using NPN transistors.
So I wonder are this NPN transistors for DTR (mark as U2 on schematic) and CTS (mark as U3 on schematic) lines necessary?
I am trying to design minimalistic custom board that would allow flashing without reset and flash buttons. I tried to follow following instructions https://gist.github.com/morganrallen/09 ... 9c2a621d50
I plan to flash upload firmware with usb to ttl serial from ebay like here:
http://www.ebay.com/itm/381292739186?_t ... EBIDX%3AIT
@morganrallen is connecting this pins dtr and rts directly but devc from espressif (https://dl.espressif.com/dl/schematics/ ... V2_sch.pdf) is using NPN transistors.
So I wonder are this NPN transistors for DTR (mark as U2 on schematic) and CTS (mark as U3 on schematic) lines necessary?
- Attachments
-
- pcb.png (216.93 KiB) Viewed 18483 times
-
- schematic.png (149.46 KiB) Viewed 18483 times
Re: wroom32 schematics
The transistors are for the case where both DTR & RTS are asserted together. When either RTS or DTS are asserted (goes low) it still pulls EN or GPIO0 (respectively) low, the same if they were wired directly. However if both are asserted at the same time, neither pin is pulled low. There's a little logic truth table in the schematic that shows this.
The reason for wanting this behaviour is that many common serial terminal programs will assert DTR & RTS by default. If you have these wired directly, it will permanently hold the chip in reset unless you reconfigure the serial program not to assert RTS.
This design was first popularised with the NodeMCU board for ESP8266.
The reason for wanting this behaviour is that many common serial terminal programs will assert DTR & RTS by default. If you have these wired directly, it will permanently hold the chip in reset unless you reconfigure the serial program not to assert RTS.
This design was first popularised with the NodeMCU board for ESP8266.
Re: wroom32 schematics
Thanks for superfast reply.
So if I modify serial.py thing would work without both serial transistors, with direct connection to io0 and en pins?
Another question: traces under wroom32 antena traces - would the way I put traces around this area not disturb wifi signal?
So if I modify serial.py thing would work without both serial transistors, with direct connection to io0 and en pins?
Another question: traces under wroom32 antena traces - would the way I put traces around this area not disturb wifi signal?
Re: wroom32 schematics
esptool.py will work with direct connections to IO0 & EN, no modification needed. Serial programs will also work as long as you configure them not to assert RTS. I often use miniterm.py which comes with pyserial, and for that configuration I use this this:zhivko wrote:Thanks for superfast reply.
So if I modify serial.py thing would work without both serial transistors, with direct connection to io0 and en pins?
Code: Select all
miniterm.py --raw --dtr=0 --rts=0 /dev/ttyUSB0 115200
This is generally a bad idea. You should keep your traces away from the antenna keep-out area. If possible, I'd also recommend pulling back the ground plane from the end of the board and moving the two SMD components in the bottom right away from the antenna, as much as you can.Another question: traces under wroom32 antena traces - would the way I put traces around this area not disturb wifi signal?
Re: wroom32 schematics
OK, after all I decided to use NPN transistors, but have problem with flashing esp32.
It seems that EN line does not fully transition from 3.3V to 0V (check scope screenshot of yellow line that represents EN). However blue line that represents IO0 does a full transition from 3.3V to 0V - so any idea what could be wrong with my schematics?
Could S8050 NPN transistor for EN line be non operational?? What else could pull EN so strong to 3.3V that it doesn't let go to 0V as IO0 does?
Check also my other attached pictures...
It seems that EN line does not fully transition from 3.3V to 0V (check scope screenshot of yellow line that represents EN). However blue line that represents IO0 does a full transition from 3.3V to 0V - so any idea what could be wrong with my schematics?
Could S8050 NPN transistor for EN line be non operational?? What else could pull EN so strong to 3.3V that it doesn't let go to 0V as IO0 does?
Check also my other attached pictures...
- Attachments
-
- IMG_20161119_020318.jpg (2.65 MiB) Viewed 18301 times
-
- IMG_20161120_002145.jpg (2.84 MiB) Viewed 18301 times
Re: wroom32 schematics
I checked official devc from espressif and there is "Auto program" table in schematics it says:
dtr=0, rts=1 --> en==1, io0=0 so this is what I am getting, but still in arduino esp32 - I get:
At the time when EN=0 and io0=1, tx and rx lines from ftdi32 are not present anyhow... So what actually "waiting for packet header" means?
dtr=0, rts=1 --> en==1, io0=0 so this is what I am getting, but still in arduino esp32 - I get:
Code: Select all
Global variables use 9,160 bytes (3%) of dynamic memory, leaving 285,752 bytes for local variables. Maximum is 294,912 bytes.
python.exe C:\Program Files (x86)\Arduino\hardware\espressif\esp32/tools/esptool.py --chip esp32 --port COM3 --baud 115200 write_flash -z --flash_freq 80m --flash_mode dio 0x1000 C:\Program Files (x86)\Arduino\hardware\espressif\esp32/tools/sdk/bin/bootloader.bin 0x8000 C:\Program Files (x86)\Arduino\hardware\espressif\esp32/tools/sdk/bin/partitions_singleapp.bin 0x10000 C:\Users\klemen\AppData\Local\Temp\arduino_build_629099/blink.ino.bin
esptool.py v2.0-dev
Connecting...
A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header
A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header
Re: wroom32 schematics
Oh and regarding rts and cts disabling in miniterm - I tried various combinations for:
in c:\Program Files (x86)\Arduino\hardware\espressif\esp32\boards.txt file.
Code: Select all
esp32.serial.disableDTR=false
esp32.serial.disableRTS=false
Re: wroom32 schematics
Regarding esp32.serial.disableDTR esp32.serial.disableRTS: unless you use Arduino IDE with a patch to support these options, they won't do anything.
"Timed out waiting for packet header means" means that esptool.py has not received a response from the ESP32 serial bootloader.
Can you attach another FTDI to observe what is happening on TX/RX lines while esptool.py is trying to connect?
"Timed out waiting for packet header means" means that esptool.py has not received a response from the ESP32 serial bootloader.
Can you attach another FTDI to observe what is happening on TX/RX lines while esptool.py is trying to connect?
Re: wroom32 schematics
Unfortunately I do not have another FTDI - only bus pirate (http://dangerousprototypes.com/docs/Bus_Pirate) - maybe I could use it.
But I think main problem here is that EN doesn't go fully to 0V to make reset - however I see io0 to go to 0V and then back to 3.3V - so this makes me believe something is wrong with schematics around EN line.
But I think main problem here is that EN doesn't go fully to 0V to make reset - however I see io0 to go to 0V and then back to 3.3V - so this makes me believe something is wrong with schematics around EN line.
Re: wroom32 schematics
Turned out I had faulty usb - serial ttl adapter.
I picked new one and here is scope trace of io0 and en line: and result from arduino ide:
So thanks for support guys and looking forward for esp32 arduino core functions!
I picked new one and here is scope trace of io0 and en line: and result from arduino ide:
Code: Select all
Sketch uses 102,069 bytes (9%) of program storage space. Maximum is 1,044,464 bytes.
Global variables use 9,160 bytes (3%) of dynamic memory, leaving 285,752 bytes for local variables. Maximum is 294,912 bytes.
python.exe C:\Program Files (x86)\Arduino\hardware\espressif\esp32/tools/esptool.py --chip esp32 --port COM3 --baud 115200 write_flash -z --flash_freq 80m --flash_mode dio 0x1000 C:\Program Files (x86)\Arduino\hardware\espressif\esp32/tools/sdk/bin/bootloader.bin 0x8000 C:\Program Files (x86)\Arduino\hardware\espressif\esp32/tools/sdk/bin/partitions_singleapp.bin 0x10000 C:\Users\klemen\AppData\Local\Temp\arduino_build_234277/blink.ino.bin
esptool.py v2.0-dev
Connecting...
Uploading stub...
Running stub...
Stub running...
Attaching SPI flash...
Configuring flash size...
Compressed 5264 bytes to 3363...
Writing at 0x00001000... (100 %)
Wrote 5264 bytes (3363 compressed) at 0x00001000 in 0.3 seconds (effective 139.9 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 78...
Writing at 0x00008000... (100 %)
Wrote 3072 bytes (78 compressed) at 0x00008000 in 0.0 seconds (effective 2234.2 kbit/s)...
Hash of data verified.
Compressed 225792 bytes to 67923...
Writing at 0x00010000... (20 %)
Writing at 0x00014000... (40 %)
Writing at 0x00018000... (60 %)
Writing at 0x0001c000... (80 %)
Writing at 0x00020000... (100 %)
Wrote 225792 bytes (67923 compressed) at 0x00010000 in 6.0 seconds (effective 303.0 kbit/s)...
Hash of data verified.
Leaving...
Last edited by zhivko on Wed Dec 07, 2016 10:13 am, edited 1 time in total.
Who is online
Users browsing this forum: No registered users and 107 guests