EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: Peabody on September 30, 2018, 09:19:50 pm
-
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.
-
Not a lot of interest in this, but in case someone runs across it decades from now (yeah, right), this is what I settled on:
https://github.com/gbhug5a/CP2102-with-BSL-Scripter-for-MSP430
-
unfortunately the first thing Scripter does is bring both lines low.
I believe that this is a consequence of the standard "open" command on a COM port.The Arduino folk made use of this side-effect to automatically invoke the bootloader when ready to upload, and then discovered that it was a pain in the neck if you wanted to open the serial connection to the board WITHOUT causing a reset. Sigh.
Nice writeup. I would have expected the timing at the other end of a USB/Serial connection from a modern windows process to not be "tight" enough to bit-bang timing-sensitive sequences. I guess I'd've been wrong.
It'd be pretty trivial with an Arduino Nano clone ($2-3) in the middle.
-
unfortunately the first thing Scripter does is bring both lines low.
I believe that this is a consequence of the standard "open" command on a COM port.The Arduino folk made use of this side-effect to automatically invoke the bootloader when ready to upload, and then discovered that it was a pain in the neck if you wanted to open the serial connection to the board WITHOUT causing a reset. Sigh.
Nice writeup. I would have expected the timing at the other end of a USB/Serial connection from a modern windows process to not be "tight" enough to bit-bang timing-sensitive sequences. I guess I'd've been wrong.
It'd be pretty trivial with an Arduino Nano clone ($2-3) in the middle.
Thanks for the comments. I thought the COM port Open might be doing it too, but haven't been able to demonstrate that. If I just plug in a CP2102 module, everything comes up high - DTR, RTS and the data lines. Then if I run my Invoke program with the scope on Single, rising edge, it only triggers on the pattern I generate - there's no initial low pulse on Open. Also, if I run my program a second time without unplugging the module, it opens the port with both lines at the state I left them in on the first run. So as far as I can see, it's Scripter that's doing this. But I haven't formally investigated it. Of course this is Silabs' virtual COM port driver for their CP2102, not a real COM port. That may make a difference.
Not sure what you're "bit-bang" comment refers to.
-
You could add a jumper to your board that makes your firmware transfer control to the BSL at startup. The jumper can be what is normally an output pin on a header, with a weak pullup and temporarily checked as an input during startup. Then you can just ground that pin and turn on power. If it's not grounded, reconfigure it for the normal output use.
The BSL location varies with family, but 0x1000 is the transfer address for F5xxx/F6xxx USB parts, e.g.:
// ... disable USB via PUR, then ...
__disable_interrupt();
((void (*)()) 0x1000)(); // Transfer control to USB BSL
PMMCTL0 |= PMMSWPOR; // Force a reset, in case it returns here
The BSL is automatically entered if the reset vector is 0xffff, this way a blank chip will automatically accept an update. The password is the contents of the vectors at 0xffe0-fffe (if memory serves), so for a blank chip is all 0xff's. If you give the wrong password during update the BSL will mass erase, and now you can flash the blank device as if it were a factory flash. (For USB devices this means a different VID/PID, but that complication isn't present for the devices without USB that use a serial port.) So if you don't go through the trouble of making sure your interrupt handlers are located to specific addresses it will Just Work anyway. The only gotcha is you lose any InfoFlash sectors in the process, so if you want to keep those you need to maintain a BSL password by making sure interrupt handlers have specific addresses. (This is somewhat easily done by creating separate link section(s) for them and relocating these to a specific address(es) at the top of the flash region.)
-
I was specifically working on the /Reset and Test hardware invocation, but yes, there is a variety of ways to start BSL via software. And as an alternative to your jumper, you could test the BSL's designated RxD pin on startup, with its pulldown resistor enabled. If the CP2102 is connected and powered up, its TxD output will idle high, so if you see a high on that line, you jump into BSL.
I've just always found it curious that TI didn't put an option in BSL-Scripter to generate the hardware invocation pattern directly, as it already did in BSLDEMO for the older parts. I've asked about that possibility, and they made it pretty clear they have no plans to modify Scripter to support the jellybean USB-to-UART adapters. They must be selling a lot of Rockets and MSP-FETs.