Arduino UNO R4 WIFI firmware update fail

The answer is that it depends on the program they loaded on the ESP32-S3, and on the program that is running on the RA4M1. There is a complex situation where the program running on either chip can easily significantly interfere with the functionality of the other.

Arduino pin 21 on the RA4M1 is connected to NLASB3157 switches on the board that control whether the USB data lines are electrically connected directly to the RA4M1 or to the ESP32-S3. So the program on the RA4M1 has the power to cut off communication between the ESP32-S3 and the computer.

Arduino pin 4 on the ESP32-S3 is connected to the RESET pin on the RA4M1. So the program on the ESP32-S3 can reset the RA4M1, including holding it permanently in reset by setting that pin LOW. In addition, I wasn't able to understand why from looking at the schematics, but if pin 4 is not set HIGH (as is done in the stock firmware) then the RA4M1 won't restart after the reset button on the board is pressed. So the program on the ESP32-S3 has the power to disable the RA4M1 completely. The program on the ESP32-S3 can also activate the bootloader on the RA4M1 by doing a double reset via pin 4 (as is done by the stock firmware when a "1200 baud touch" is received).

I wrote: "(under certain conditions) the USB code that creates the CDC serial port is running on the same microcontroller as your sketch" in post #15. The specific conditions I was referring to were:

  • The program on the RA4M1 sets pin 21 HIGH
  • The program on the RA4M1 creates a CDC serial port

Those conditions are produced when the program on the RA4M1 #includes the "HID" library (which is more commonly done transitively via a higher level library like "Keyboard" or "Mouse").

But as soon as you activate the bootloader on the RA4M1, the sketch program that would produce those conditions stops running, so the USB data lines are switched to being connected to the ESP32-S3. This means that if the program running on the ESP32-S3 doesn't provide the necessary "bridge" capabilities then it will no longer be possible to upload programs to the RA4M1.

The only exception is if the "RA4M1 USB" solder jumper on the bottom of the UNO R4 WiFi board has been shorted, which causes the NLASB3157 switches to be permanently set to connecting the USB data lines to the RA4M1. In this case the computer can still communicate directly with the RA4M1 even when the bootloader is activated, rather than being dependent on the ESP32-S3 acting as a "bridge".