Outboard DFU - ESP32 S3 Not Working


I am working with the following:

I am having trouble getting Outboard DFU working with my current setup. I have the following connections between the Notecarrier and ESP32:

  • Notecarrier AUXRX → ESP32 TX

  • Notecarrier AUXTX → ESP32 RX

  • Notecarrier AUX3 → ESP32 GPIO 0

  • Notecarrier AUX4 → ESP32 RST

I’ve been able to get to the point in the process of the Notecarrier trying to flash the ESP32. I see the ESP32 being put into DFU mode and “waiting for download”. I then wait for the Notecarrier to flash the device but nothing happens. I have connected an oscilloscope to the Notecarrier AUXTX pin to make sure data is being sent. When the AUXTX is connected to the ESP32 RX pin, I see the logic levels change from 3.3V to roughly 3V. However, if I leave AUXTX floating and don’t connect it to the ESP32 RX pin, I see the full logic level shift from 3.3V to 0V when data is being sent. I’m confused here at what is pulling up the AUXTX pin when it is connected to the ESP32 RX pin to prevent data from being sent correctly. When I flash the ESP32 over UART from my computer, I see the ESP32 RX pin logic level shift from 3.3V to 0V normally on my oscilloscope. Does anyone have any insight on what is happening here? I’ve searched all over the Blues forum and other ESP32 related forums to try and find an answer.

Any help would be appreciated.


Hi @marcel, glad to have you in the forums!!!

Well, it sounds like you are doing everything right, but in situations like this a picture may be more revealing. Are you able to snap a photo of your wiring and setup? Maybe something obvious will appear.

Also, which version of the Notecard are you using, and which version of it’s firmware?
Also, are you using one of our SDKs? If so, which one?


Hi Zak @zfields ,

Here are pictures of my setup. Let me know if you need a better angle.

I am using the Notecard Cellular LTE Cat-1 | North America running firmware version
I am using an Arduino environment with the Blues Wireless Notecard Arduino library version 1.4.1.

Thanks for the help, let me know if you need more information from me.


Wow, nice diagrams! Honestly, that looks pretty good.

I would try swapping around the power. The Notecard is staying on and performing the DFU, so I would make it the primary, or at least provide it with it’s own battery.

Otherwise, I would be curious if the TX/RX lines you’ve chosen are the ones used to write to the flash. Do you happen to have a schematic or pin out for your ESP32-S3?

That’s off the top of my head. If those suggestions don’t bear fruit, then I will try to dig deeper with you.

Also, it won’t fix your problem, but it’s definitely worth updating note-arduino. It’s had quite I few stability enhancements.



I’ve made the Notecard the primary and this made no difference.

Here is the pinout for the ESP32-S3 I am using:

We are connected to U0TXD and U0RXD. I see my ESP32 be put into the boot mode of DOWNLOAD(USB/UART0), which would indicate to me that it is looking for flash data on UART0. See these docs - Boot Mode Selection - ESP32-S3 - — esptool.py latest documentation

Here are the docs for the ESP32-S3 I am using - ESP32-S3-DevKitC-1 v1.1 - ESP32-S3 - — ESP-IDF Programming Guide v5.2 documentation

Any other suggestions you have would be appreciated.

I also have updated our note-arduino library to the most recent version, thank you for noting that.


It’s interesting the U0TXD and U0RXD are holding the lines high. That makes me think you should try the other interface U1TXD and U1RXD on pins 17 and 18.

Have you given those a shot yet?


I have tried the U1TXD and U1RXD interface on pins 17 and 18 and did not have success. The U1TXD pin was not held high though just for reference. It seems like I should be using UART0 based on the boot mode the ESP32 is being put into (DOWNLOAD(USB/UART0)).

Any other things you can think of I should try?


Does the RST pin on your board reset the device when it is pulled HIGH or LOW?

In other words, what is the voltage on the pin when it is running normally?

Our reset pin drives the line LOW to reset the board. If the ESP32-S3 is actually a RST pin and not an NRST pin, then perhaps this is the hang up.


I can confirm that the RST pin on my board resets the device when it is pulled LOW. I proved this out by connecting my RST pin to GND and saw the ESP32 then reset.

Hi @marcel,

Looking deeper, the ESP32-S3 schematic shows two resistors that connect UART0 to the USB, R7 and R9.

Have you tried running ODFU without anything connected to the USB port?

I’m afraid you may need to remove resistors R7 and R9 to prevent USB from interfering with ODFU. However, if you do this, then you will almost certainly lose the ability to flash firmware over USB. Personally, I would have two of these devices handy before I proceed.

ESP32-S3 Schematic:

Technical Reference Manual (ESP32-S3):



I had tried running ODFU without anything connected to the USB port a few times and never had success.

I just removed R7 and R9 on one of my boards and was able to successfully perform ODFU. It seems I will need to select a different ESP development board that does not have the USB to UART bridge as pictured in the screenshot you sent.

Thank you for your help with this!



Do you agree that I would need to find an ESP32 development board that does not have the USB to UART bridge in order to perform ODFU? Since that IC is interfering with the RX/TX on the ESP32. Unfortunately, it looks like all Espressif development boards have this bridge on them. I say unfortunately because they are very easy to source and usually have large numbers in stock. The project I am working on may eventually require hundreds to thousands of these boards.

I have tried out the Swan, but would prefer to stay with an ESP32. I’ve seen other people on the Blues forums use the Unexpected Maker ESP32 S3 - FeatherS3 - ESP32-S3 Development Board by Unexpected Maker : ID 5399 : $22.50 : Adafruit Industries, Unique & fun DIY electronics and kits
This one looks like it will work for me and allow me to perform ODFU with no issues, however I am concerned about sourcing the board at high volumes.

Hi @marcel ,

First, I’ll start with telling you that any suggestion I make is made in a vacuum, because I have no idea about constraints of your business. With that being said, I will gladly hazard a guess.

It sounds like you are planning to take a product to production with 100’s or 1000’s of boards. Surely, you don’t want your production devices to have USB access in the field; that sounds like an enormous security vulnerability. If this is the case, then disabling the UART bridge will not be a problem. Otherwise, If you plan to design your own PCB, then you can just omit the UART bridge, and have a programming port connected to UART0. Then you can program the device at the factory and use the Notecard to deploy firmware updates subsequently.

That’s just my two cents without knowing anything about your business, and it should be taken with a grain of salt.