Page 1 of 1

ESP32 - create an upload stub - problem reading RX after stub running

Posted: Wed Oct 22, 2025 7:10 pm
by Geir_Moen
I may have bitten over more than I can chew, but this should not be the problem that kills the project...
I am trying to create an offline bulk programmer for ESP32 chips.

Talking to ChatGPT for about a week now, I asked it to recommend forums or FAQs instead of pulling me along in an endless circle of failures.
ChatGPT did teach me how to set up VisualStudio Code to compile as "bare-bone" stub and strip off all Arduino and platformIO functions. This is important when creating stub because of image size.

Anyways - Without any settings, I can make the stub send me data via TX (UART0, GPIO1, pin35), but RX (UART0, GPIO3, pin34) does not detect any incoming data.
ChatGPT tells me that when uploading to RAM (stub upload), the control of TX is transferred to the stub correctly, but the RX is often disabled for some reason. Problem is that ChatGPT were not able to help me re-enable RX without screwing up the entire UART0 controller.

Does any of you know what registers I need to contact and what bits I need to clear/set to get my RX pin to work properly?


Kind regards,
Geir Moen

Re: ESP32 - create an upload stub - problem reading RX after stub running

Posted: Thu Oct 23, 2025 1:21 am
by Sprite
Sounds like an XY problem. What are you actually trying to achieve, what's the bigger picture here?

Re: ESP32 - create an upload stub - problem reading RX after stub running

Posted: Thu Oct 23, 2025 2:46 am
by ok-home

Re: ESP32 - create an upload stub - problem reading RX after stub running

Posted: Thu Oct 23, 2025 4:08 am
by Geir_Moen
Ooo!
This looks like a gold mine.
I will definitely learn a lot from this.
Thank you so much!

Kind regards,
Geir Moen

Re: ESP32 - create an upload stub - problem reading RX after stub running

Posted: Thu Oct 23, 2025 4:52 am
by Geir_Moen
Sounds like an XY problem. What are you actually trying to achieve, what's the bigger picture here?
There are 2 main microcontrollers that I use frequently. This is Atmel (now MicroChip) and ESP32.
My projects are some times with sale in mind, and that involves flashing a new microcontroller with fully developed firmware.
Not a problem, but opening VisualStudio Code with PlatformIO and re-activating old project and re-compile it for upload takes a lot of time. And if an update has been requested, then hours may go by trying to get the systems up and running again.

Last month I created an Offline programmer for most of the Atmel chips (ICSP chips only) and I'm pretty happy with this. That ended up with a hope to make an offline programmer for ESP chips as well.

Enough back-story - Here are some details regarding my project and the actual issue;
I use an ESP32-WROOM32 for a "master" controller. This is the one with user buttons, a 20x04 LCD and a connector to connect the "slave" ESP microcontroller.
Master triggers 2 MOSFETs to fake Reset and Boot pins on the "target" chip and sends it into boot-mode.
Master sends sync sequence until target responds correctly.
Master sends request to determine target chip family (aka Chip magic number)
All of this works perfectly.

Here's the tricky part:
If the user wishes to clean/wipe the target chip, I will need to upload a small stub to the target chip and have the stub perform the actual clean procedure (at least recommended according to ChatGPT)
Also, if the user wishes to backup or write a new chip, I will need to upload a stub and have it perform the target-side-workload (at least recommended according to ChatGPT)

So, with some help, I created my first stub using VisualStudio Code and had it strip all framework from the compiler (often called "bare-bone" code)
Using VisualStudio Code to upload the stub, it has no problem sending back "Hello World" to my PuTTY terminal. However, the old ping-me-back test fails every time.
According to ChatGPT (I have no way of knowing the accuracy on this); "When the boot loader hands over control to a RAM loaded stub, it leaves the TX registers in tact, but it disables RX." Personally, I'm skeptical but who am I to question this?

So I've been dragged around in circles for about a week now trying to re-activate the RX functionality of the UART0 after my stub is uploaded and run on the target ESP chip.
How does the esptool.py handle this issue? And is it actually an issue, or will this magically disappear when the stub is uploaded the normal way by my master chip?

I am sorry, I'm terrible at reading Python scripts, so what I'm hoping for is what registers I need to change and in what order - to be able to fully communicate with the stub again?


Kind regards,
Geir Moen

Re: ESP32 - create an upload stub - problem reading RX after stub running

Posted: Thu Oct 23, 2025 8:02 am
by MicroController

Re: ESP32 - create an upload stub - problem reading RX after stub running

Posted: Thu Oct 23, 2025 2:47 pm
by Geir_Moen
Frankly, Yesterday was the first day that I was aware of this forum. I do know that septool has got the stubs with the functionality that I want, but ChatGPT directed me to a dead link on Github. I think maybe that your link is the one that I should have been referred to.
I will definitively check this out!

Thank you so much!

Kind regards,
Geir Moen

Re: ESP32 - create an upload stub - problem reading RX after stub running

Posted: Fri Oct 24, 2025 8:18 am
by MicroController
Here's the tricky part:
If the user wishes to clean/wipe the target chip, I will need to upload a small stub to the target chip and have the stub perform the actual clean procedure (at least recommended according to ChatGPT)
You don't need a stub for this. You can just use the bootloader in ROM to do the basic operations, cf. https://docs.espressif.com/projects/esp ... er-no-stub

(Notice that ChatGPT is obviously not good at providing reliable information. Before being driven in circles next time, refer to the actual documentation and Espressif github. And of course this forum :) )