I am attempting to modify a clone MEGA 2560 R3 board so that it cannot be powered by USB.
Most people say "Remove the fuse" or "Remove T1" which are both solid suggestions for other boards.
On an Arduino DUE, removing T1 and T2 absolutely has the desired effect.
Removing either of those on this 2560 board results in non-functional USB. I can put them back on and USB works again, but the board is powered by USB again.
I found this post from years ago, which seemed promising:
Wherein we find this nugget of wisdom:
CrossRoads: Ok, if you replace F1, and remove T1, that will remove the USB-VCC path, while allowing the USB/Serial interface to remain powered.
However, Reset is pulled High to 5V, so you will also need to remove RN5 (resistor pack) and D2 and wire in a resistor/diode to bring Reset2 to USBVCC, and put a 10K resistor across pins 1/8 for the 2560 Reset pullup. The other 2 resistors in the pack are used for autopower switching, which is disabled with the removal of T1, and don't need replacing.
So after studying the schematic and board layout, I removed RM5, T1, and D2, and installed the 10k resistor and a diode (1n914 in this case) between RESET2 and USBVCC, and 10K resistor between VCC and RESET.
This does not work. USB is disabled. The board boots normally if external power is applied but USB is completely nonfunctional.
If I reinstall T1, USB works again but the board is again powered by USB.
I have fairly decent soldering skills, a long narrow 700f tip on my weller wtcpt, and a hot-air rework system, so i have had T1 on and off maybe half a dozen times now.
I imagine that things are different on clones that use a WCH or FTDI serial chip, but i don't have and don't want one of those.
For the curious, I want to do this because the board in question is intended to be the brains of a 3d printer controller with a RAMPS and TMC2130 stepper drivers. The TMC2130 needs VMOT to be powered before VCC, where VMOT is the 12v or 24v supply for the 3D printer. If you power up the board with VCC and no VMOT, Marlin firmware correctly throws an error and halts to prevent burning out the driver.
This means that I would have to turn on the printer before connecting USB unless I can prevent the USB circuit from powering the rest of the board. Since the printer is remotely managed with Octoprint, and the larger plan includes building a circuit to allow Octoprint to cut the power to the printer via a relay (important in the eventuality that a mosfet fails in the ON position potentially leading to a thermal runaway condition that cannot be avoided through the printer firmware), this is kind of inconvenient.