ESP32 as ISP

[hgptamn]

Hi!
Is there a way to use an ESP32 as an ISP for another ESP32?

I have managed to access the external flash of the board that needs to been programmed, by exposing it's pins and disabling it's CPU (by tying CHIP_PU line to GND). This way the external flash memory that needs to be programmed it's not tied to it's main ESP32 chip and it's free to be accesed via SPI by another ESP32.
I've tried simple commands like reading the JEDEC ID (0x9F) and they do work.
However I haven't been able by now to find any way to write the main bin files (bootloader.bin, partitions_singleapp.bin, example.bin) using the ESP32 programer board as an ISP.

Here is a visual representation of the system:

Programmer-visual.png (238.17 KiB) Viewed 16625 times

[hgptamn]

Nobody?

[ESP_Sprite]

What's your question exactly? The only one you actually ask is 'is there a way to program an ESP32 from another ESP32', which has the quite predictable answer 'yes there is, you seem to be on your way to implement one of them'. The implicit one in the rest of your story seems to be 'why can I send simple commands but not program the chip', and there's not enough information to even start answering that question.

[hgptamn]

@ESP_Sprite
A good starting point would be:

However I haven't been able by now to find any way to write the main bin files (bootloader.bin, partitions_singleapp.bin, example.bin) using the ESP32 programmer board as an ISP.

The question in cause would be: do you know of any way to load those bin files to the target system using the programmer board?
A slight suggestion in the right direction would be greatly appreciated; in case you need further info I'm here to provide it.

[Vader_Mester]

@hgptamn
The method you need will depend on the implementation of the ESP32.

So my questions are:
1) Would you use an existing module (WROOM, WROVER, ALBWROVER etc) in your project? In this case I guess you need programming and verification before soldering
2) Do you design a circuit yourself, with the ESP32 mounted on your board? If this is the case, than the question here is why do you want to disable the ESP32 while programming? (do you want to avoid powering up other components on your board?)
3) You want to be speedy with the programming (that's understood in a production environment), than directly interfacing the flash is a way to go. I think there are programs already available for interfacing an external SPI-flash, for which simply writing to the programmed flash should not pose any issue.

If you only want to program an existing module, there are jigs you can buy online where you snap the module in, program it with UART, remove it from the jig and solder onto the board.
Check my post below. This module first WROOM and ALBWROVER modules. There is also a version for the WROVER module (I currently have the WROVER verysion).
https://esp32.com/viewtopic.php?f=2&t=4180

Another way could be to have the UART pins exposed as test pads, as well as the 3.3V supply, and use these points for interfacing the ESP32 for programming. For this a test fixture can be used with ease (contact using POGO pins), or a programming connector, can be used. Using this method, programming and functional testing afterwards can be done within 1 fixture - a good solution for production environment.

If you don't wan't other stuff on your board to come live while programming, you can use isolate the power line that is only used for programming, using a MOSFET (There are MOSFETS that are so small, they are as small as a resistor, so not really consuming much space) This way - since the programming is managed on the ESP on bootloader level, and this should not interfere with anything connected to it - then you can use the UART for programming. And you can of course use another ESP as ISP in this case but using UART. If you strap the pins right on the target ESP, than it will wirte to flash the data it received on UART from the programmer ESP (as fat as I know).

By the way, interfacing only the flash in my opininon looses some options for configuring the ESP, and it means loosing some features such as flash encryption or secure boot, if this is going to be a commecrial product.

[hgptamn]

@Veder_Mester

1) The programmer can be any ESP32 board out there, but for reference I use a Sparkfun ESP32 Thing as the main programmer along with a shield which routes the SPI pins of ESP32 Thing + CHIP_PU + 3V3 + GND to some tactile pads. Those pads are the ones which interface with the board that needs to be programmed.

2) The "Board to be programmed" is a custom PCB design which exposes the external SPI flash pins on some pads for ease of access. These pads come in contact with the tactile ones mentioned at 1). The purpose of disabling the CPU of the programmed board is to release the flash from being used by the programmed board, thus avoiding a conflict on the same resource (which is the serial flash). (ESP32 and the serial flash IC share the same 3.3V power supply).

3) The problem over here does not relate to concomitent access to the flash (the board that needs to be programmed has its main CPU disabled); it releates to uploading the bin files to the external serial flash using the ESP32 as an ISP

Such a jig that you mention it's actually the programmer on my system which has some tactile pads that connect to the SPI flash interface on the board that needs to be programmed.

I do have the UART pins exposed on the tactile pads, but the goal is to program the serial flash via SPI.
To simplify this hole process imagine this:
You have an SPI serial flash connected to a generic ESP32 dev board via SPI. How do you upload the binaries (bootloader.bin, partitions_singleapp.bin, example.bin), to their respective addresses (0x1000, 0x8000, 0x10000)?

[WiFive]

https://esp32.com/viewtopic.php?f=17&t=4666

It would be easier to hold the esp32 on the programmer board in reset and connect the USB uart pins to the target board but maybe you had a reason not to do that

[hgptamn]

@WiFive
Thanks for the link! I was experimenting with https://github.com/Marzogh/SPIFlash

However, UART programming is not an option for the project I'm trying to develop; if it was I wouldn't have bothered with this setup.
SPI flash programming using an ESP32 programmer board is the goal in my case.

[Vader_Mester]

@ ESP_Sprite
This thread got me thinking about something.

In the PICO-D4, if I disable the chip with the EN pin, is it still possible to access the FLASH externally?
All flash pins are exposed on the PICO pasckage, there is a VDD_SDIO_NC pin on the PICO, it says that it is NC, but technically it's possible to connect to this pin (only for flash programming) and interface the flash without the rest of the ESP chip working?

I assume here that in case of the PICO, the SDIO voltage is 1.8V.

Thanks for the answer.

[hgptamn]

@ ESP_Sprite
This thread got me thinking about something.

In the PICO-D4, if I disable the chip with the EN pin, is it still possible to access the FLASH externally?
All flash pins are exposed on the PICO pasckage, there is a VDD_SDIO_NC pin on the PICO, it says that it is NC, but technically it's possible to connect to this pin (only for flash programming) and interface the flash without the rest of the ESP chip working?

I assume here that in case of the PICO, the SDIO voltage is 1.8V.

Thanks for the answer.

Yes you can, I've tried it. In fact, the board that I want to program externally via SPI has exactly this chip on it (ESP32 PICO-D4) + S25FL164K serial NOR flash.