Can the RTS pin be held LOW during the program upload process?

[Grunwalskii]

Hello everyone,

I'm working on a project involving a custom Attiny1616 development board that I designed. The board includes a multiplexer and a CH340 chip to switch between UPDI and Serial. I'd like to keep the RTS (Request to Send) pin LOW throughout the entire program upload process to ensure the UPDI is enabled via the multiplexer.

I've explored the programmers.txt file but couldn't find a way to achieve this without overwriting the upload scripts. Is there any way to configure this behavior through software, or am I limited to modifying the upload scripts?

Any insights or suggestions would be greatly appreciated!

Thank you!

Edit 1:
I measure a 18ms RTS Low signal when uploading, BUT only one the first upload. I have to unplug the CH340 programmer and reinsert it. Then the next upload pulls the RTS Pin low for 18ms.
Why does the RTS Pin stays high after the first upload?
So please, point me in the right direction to set the RTS Pin low for the duration of the upload.
I would like to have it as a selectable Programmer so that other users can easily use AtTiny Dev boards with Multiplexers to automatically switch between UPDI and Serial.
This would also allow for an external Programmer that can switch between both modes.
Maybe if the RTS pin is not used at the moment, this could be the default behavior of the megaTinyCore?

Edit 2: SOLVED !!!
I discovered that the RTS pin is LOW when the Serial Monitor is open and HIGH when its closed.
I just reversed the Logic on the PCB with a transistor and now its auto switching between UPDI and Serial

[SpenceKonde]

Are you using SerialUPDI? There are optional command line switches that will manipulate dtr and rts - I specifically keep DTR and RTS off (this was one of the changes I made to SerialUPDI from the microchip tool) because I had plans to make use of them to control an HV programming mechanism. To change which ones the IDE uses, that's in platform.txt (note that you want to look at the version of platform.txt that's there, not the one in github, unless you did a manual install. Platform.txt for board manager installations is slightly different, because SerialUPDI is in a different place)

As it happens, that 18-ms glitch you describe is uh, problematic in my situation (though it was not the only problem I encountered - I think there may be some sort of hex (as in voodoo, not as in hexadecimal) on those who would use the modem control lines to switch between serial and UPDI, because every attempt has had a pileup of issues.... like I'll assemble them and of all the boards I assemble, there were only 3 that needed obvious rework after reflow. All three of them were the test versions of that board, and none of the other more complicated boards have any problem. A board from the "100% e-tested" manufacturing partner... I mean, I guess maybe they did test it and just decided to send it out anyway, but.... So I get a board that isn't defective (as far as I could tell) into what I believe to be the correct configuration. Then the mux chip let it's smoke out, so apparently not.... And I haven't even installed the HV source for HV programming!

and at that point I got annoyed with the whole thing and investigated the dual port CH serial chip >.>

[Grunwalskii]

I uploaded my updated schmatic, this should explaine everything. Im using a USB 2.0 Multiplexer because its tiny and cheap. I also build a programmer, there I included a 100nF capacitor and a 100k resistor to never be affected by the 18ms Switch of the RTS Line.
It works fine. Normal Operation RTS is high and UPDI is "active". After Upload Open the Serial Monitor and it switches to Low, activating the RX TX lines of the attiny. You can even leave the Serial Monitor Open, when uplaoding arduino IDE switches again.
Thanks for your Work!
If I can Help you further, let me know. Greetings from Germany