The UART BSL function on TI's MSP430 MCUs is invoked by a special pattern on the /Reset and Test pins - shown in the first two pictures below. Older parts are flashed with TI's BSLDEMO.exe program, which generates that pattern on the COM port's DTR and RTS outputs. But newer parts are flashed with BSL-Scripter.exe, which requires that the pattern be generated by the hardware interface - such as the "Rocket" programming device ($10) or MSP-FET debugger ($110). I'd like to find a way to use Scripter with a jellybean USB-to-UART adapter, such as the FT232, CH340, or (my favorite) CP2102 ($1-2), which might even be embedded in a project so the only hardware needed for firmware updates is a USB cable.
I've suggested to TI that they modify Scripter to include the INVOKE command-line option, which would cause Scripter to generate the needed pattern on DTR and RTS and thereby support these third-party adapters - and sell fewer Rockets and MSP-FETs. Yeah, right. I've also looked at recompiling the Scripter source to that effect, but that's just beyond my abilities. If anyone wants to volunteer to do that, we should talk.
Meanwhile, all we really need to do is run my Invoke.exe program before running Scripter. Invoke generates the needed pattern, then closes the port - leaving DTR and RTS at their required states (high and low, respectively). But unfortunately the first thing Scripter does is bring both lines low. Since DTR is connected to /Reset, that aborts the BSL operation and puts the target chip into reset, which, you know, is not what we want.
So I've been working on a way to let Invoke do what it needs to do with both lines to invoke BSL, but then prevent Scripter from bringing DTR low. I've come up with two designs so far.
The first picture shows the use of a single-gate analog switch whose active-high Control pin is connected to a D/R/C delay circuit driven by the RTS line. The switch would allow DTR to connect to /Reset while the capacitor remains charged, particularly during the A-B period, but disconnect them when RTS stops changing and stays low. Inherently this results in very slow transitions on a CMOS input, which I'm told is a bad idea. It also raises the question of from which side the switch is to be powered, and what happens if voltage is applied to a pin when the switch is powered down.
The second picture replaces the switch with a single N-channel MOSFET. The orientation appears to be backwards, but really isn't when you consider that we are controlling the flow of conventional current from /Reset's pullup resistor into DTR when it's low. Anyway, the bottom line is that current will flow through the MOSFET only when the Gate is high and the Source is low. That's the only time when there is sufficient positive Gate-Source voltage differential to turn on the device. That occurs because of the capacitor during the Invoke sequence, but once RTS goes low permanently, the switch is opened, and DTR can no longer pull /Reset low. The body diode would still allow DTR to bring /Reset high, but that's ok because it's high anyway. I like this version better than the first one.
But there are other possibilites, including latching DTR in some way at point C or thereabouts. Also, I have to keep reminding myself that it may be possible to do everything that's needed here using a single dirt-cheap 8-pin MCU. I don't quite see how it would be triggered to generate the invoke pattern, but that could be something as simple as powering it from the CP2102's 3.3V output, and having it just wait one second before sending the pattern. But I still have concerns about voltage at the pins of a powered-down device - protection diodes and such.
I have parts arriving maybe tomorrow for testing, but in the meantime I've included a third picture showing scope traces of the RTS line and the Control pin or MOSFET Gate voltage that results from the D/R/C circuit. I should also say that while the pattern needs to remain roughly as shown in the first two pictures, it could all take place much faster, or even slower, than shown. The pulse shown as being 10 ms could actually be as short as 110 µs.
I'd like to get comments on my two designs, but I'd also like to hear if anyone has a better idea. It needs to be low parts count, dirt cheap, and foolproof even when the USB cable is not plugged in.