This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430G2231: Flashing without using the Launchpad?

Part Number: MSP430G2231
Other Parts Discussed in Thread: MSP-GANG, MSP430G2553

I'm participating in a project with a number of other people, and it requires frequent re-flashing of firmware in a G2231 processor.  Everyone has had to buy a Launchpad to do the flashing.  But I wondered if in a future version a small circuit board might be available that could be incoporated into the device and used for USB-to-SBW conversion to flash the chip.  In other words, we would continue to use the TI command line flasher and USB drivers normally required for the Launchpad, but replace the Launchpad itself with a much simpler, smaller and cheaper circuit, which is useful only for flashing.

As an example of this kind of thing, I recently put together a kit that uses an STC microcontroller, and the only hardware needed to flash that chip via USB is a very small USB to UART interface board using the CP2102 chip, which was only $1.62 delivered from China.  So I would be looking for something similar that does USB to 2-wire JTAG, and that would still work with the TI flashing software.

Is there such a thing that works with MPS430 parts?

  • There is no USB to SBW bridge chip, like USB to UART.

    Low cost solution will be to use BSL Scripter with simple hardware (USB to UART bridge) interface. Unfortunately, your device does not have BSL. Maybe you can replace it with another device with same pins, peripherals and cost, but with included ROM BSL.

    http://sustburbia.blogspot.hr/2016/02/the-great-msp430-bootloader-swindle.html

    TI eZ-FET Lite is open and updatable, so you can made it by yourself on very small board and use it for SBW flashing. It is more expensive than BSL.

    http://forum.43oh.com/topic/5530-custom-ezfet-lite/

    Also, there is my MSP-GANG like flasher with 3.8 x 3.8 cm (1.5 x 1.5 in) board, that doesn't need installation, and working on...

    • any Linux I tried: Ubuntu from 10 till 16, Fedora Workstation x86_64 23.10, openSUSE Leap 42.1 x86_64, CorePlus 6.4.1 (bootable USB stick)
    • OS X from Lion (10.7.5) till Yosemite (10.10.5)
    • Windows XP / 7

    with 2 CDC / UART bridges. But price is higher than DIY eZ-FET Lite.

  • zrno soli said:

    There is no USB to SBW bridge chip, like USB to UART.

    Low cost solution will be to use BSL Scripter with simple hardware (USB to UART bridge) interface. Unfortunately, your device does not have BSL. Maybe you can replace it with another device with same pins, peripherals and cost, but with included ROM BSL.

    http://sustburbia.blogspot.hr/2016/02/the-great-msp430-bootloader-swindle.html

    Thanks very much.  The sustburbia link is very interesting.  The author says he found a way to do exactly what I want to do, except I assume it would have to be for a 2553, not a 2231 which has no BSL.

    But unfortunately, the link to part 2 of that post is bad, as is the link to the friendly Russian who wrote MSPFET.EXE, which appears to be the key to making it all work.

    So it appears that, as you said, there is no USB-to-SBW chip, and therefore no easy and inexpensive way to make this work for the 2231.  But if I can find the friendly Russian, or whoever does the susburbia site, it's possible I can get this to work, at least for the 2553 or 2452.

    I'm not familiar with BSL Scripter.  I'll try to find that.

    Thanks again.

  • George Hug said:
    But unfortunately, the link to part 2 of that post is bad, as is the link to the friendly Russian who wrote MSPFET.EXE, which appears to be the key to making it all work.

    But if I can find the friendly Russian, or whoever does the susburbia site, it's possible I can get this to work, at least for the 2553 or 2452.

    I'm not familiar with BSL Scripter.  I'll try to find that.

    AFAIK there is no MSPFET.EXE related to MSP430 BSL. There is TI BSL Scripter (open source) that is used for PC side...

    http://www.ti.com/tool/MSPBSL

    You can find also other (ask Google) open BSL design for MSP430 devices...

    http://www.flyingcampdesign.com/msp430-bsl-programmer.html

    Here you can see what I was using for BSL when UART still was present on PC's.

    http://forum.43oh.com/topic/3948-ttl-uart-and-ftdi-what-is-what-and-for-what/?p=35957

  • zrno soli said:
    AFAIK there is no MSPFET.EXE related to MSP430 BSL. There is TI BSL Scripter (open source) that is used for PC side...

    http://www.ti.com/tool/MSPBSL

    You can find also other (ask Google) open BSL design for MSP430 devices...

    http://www.flyingcampdesign.com/msp430-bsl-programmer.html

    Here you can see what I was using for BSL when UART still was present on PC's.

    http://forum.43oh.com/topic/3948-ttl-uart-and-ftdi-what-is-what-and-for-what/?p=35957

    The MSPFET.exe in question appears to be this one:

    edaboard.com/thread18254.html

    For some reason TI won't let me enter a link here, so you'll have to copy and paste I think.  In any case, that's the software written by the "friendly Russian" referred to in that other link.

    On another point, it appears that Scripter doesn't support the 2553, and that BSLDEMO2 is what I would need to use.  But there's no longer any support for that.  It is "deprecated".

  • zrno soli said:
    Low cost solution will be to use BSL Scripter with simple hardware (USB to UART bridge) interface. Unfortunately, your device does not have BSL. Maybe you can replace it with another device with same pins, peripherals and cost, but with included ROM BSL.

    This is way to go, especially if project is just about flashing and not debugging.

  • Well I appear to have struck out.  To recap, the idea is to embed a CP2102 USB-to-UART chip and a mini- or micro-USB socket in the circuit containing the G2553 processor (since the G2231 has no BSL).  Then the user would be able to flash new firmware without having to buy a Launchpad.  He would need to have the driver for the CP2102 installed, the file containing the new firmware, a USB cable, and the software that would implement the flashing.  But it's that last part that's the problem.

    I finally found a version of MSPFET.EXE from 2010 on a French site, but looking at its lengthy list of target devices, I find no entry for any "G" parts.  So I don't know if it's compatible with the G2553.  And I've found no instructions or help, and get no responses to emails to the author.  I don't know if the 2010 version is the latest.

    I have confirmed that BSL Scripter does not support the G2553.

    So that leaves something called BSLDemo2.  I found that in the "Deprecated" folder of the zip file containing Scripter, along with several possible patches, with no explanation of any of that, and I've found no information on BSLDemo2 anywhere on TI.com, or how it's to be used.

    So I've pretty much come to the conclusion that I can't get there from here unless I write my own program to do this, which I was hoping to avoid.  Actually, I shouldn't have to do that.

    Well, if anyone here has actually done this, please let me know what software you used.

  • George Hug said:
    He would need to have the driver for the CP2102 installed, the file containing the new firmware, a USB cable, and the software that would implement the flashing.  But it's that last part that's the problem.

    You can find BSL Scripter with MSP430G2553 test script inside slaa535 LaunchPad-Based MSP430 UART BSL Interface.

    This is related to BSL where LP is used as hardware base, but I guess that it will work with USB-UART bridge too.

    I used attached files for Windows.

    BSL_MSP430G2553.zip

  • Thanks very much. I will study all of that and see where it leads. SLAA535 was written by Leo Hendrawan, a TI guy who was also involved in something called OpenBSL, which as I recall dealt specifically with G-series parts.  Maybe I'm getting closer.

  • The SLAA535 material deals with using a G2231 installed in the Launchpad with firmware that provides the missing even parity bit that's not supported by the Launchpad. So in theory the Launchpad with 2231 would be the equivalent of the CP2102 that I want to use. But I would need the software I use to specify even parity to the CP2102 driver since that in turn is required by the BSL in the target chip. It's not clear what the version of BSLDEMO2 used in SLAA535 does with parity. That version has a file length of 68K, whereas the version included in the more recent Scripter zip is 224K bytes, so apparently not at all the same file unless there's compression going on, which I don't see. The only source code I have is for the larger version, and it appears from that source that even parity is specified when opening the COM port, which is encouraging.

    But at this point all I know to do is try both versions of BSLDEMO2 when the CP2102 module comes in, and hope that at least one will work.
  • After spending time researching the Info-A problem on BSL mass erases, I believe I'm going to drop this idea. The G2553 has calibration data in Info-A, and the nature of this project is that an update might be made to any one of a number of previous firmware versions, or to a new (erased) chip, or to a chip with Blinker on it, so I can't be certain what the password (interrupt vector table) would be, and it appears that the process of guessing would erase the contents of Info-A.

    A solution for updating from multiple previous versions might be to have the interrupt vectors be fixed pointers to a jump table just below FFE0. So the interrupt vectors at FFE0 would be the same for all versions, but the contents of the jump table would change. But that still leaves the issue of flashing a new chip, or a chip that was used for some other purpose entirely.

    I would say that just from the point of view of a lowly user of these products, the decision to have a BSL mass erase wipe out the calibration data was not well thought out.

    Anyway, I think I am back to the original idea, which is to somehow implement 2-wire JTAG flashing via a CP2102 embedded on the target PC board, instead of through a Launchpad, so that only a USB cable would be needed to flash new firmware. That method would preserve Info-A, and bring the G2231 back into consideration.

    That method would involve no transfers through Tx/Rx, but rather twiddling the DTR and RTS outputs of the CP2102, and reading back through input control lines when data is flowing back to the PC. I know the output part works because DTR and RTS can be used to transmit the BSL entry pattern to TEST and /RST, but I don't know how well that would work at fast speeds (although I'm not sure it has to be fast).

    So I need to do more research into TI's JTAG command line flasher and USB driver. I don't have high hopes that the flasher could be used as is, but maybe the source is available somewhere. My memory is that the third party devices from Elprotronics and Flying Camp Design are all BSL flashers, but I will double-check that. If anyone has any suggestions, let me know.

    I still need to find the mysterious Kurt, the author of mspfet.exe, whose website used to be:

    kurt.on.ufanet.ru

    and who has already done this.
  • George Hug said:
    Anyway, I think I am back to the original idea, which is to somehow implement 2-wire JTAG flashing via a CP2102 embedded on the target PC board, instead of through a Launchpad, so that only a USB cable would be needed to flash new firmware. That method would preserve Info-A, and bring the G2231 back into consideration.

    That method would involve no transfers through Tx/Rx, but rather twiddling the DTR and RTS outputs of the CP2102, and reading back through input control lines when data is flowing back to the PC. I know the output part works because DTR and RTS can be used to transmit the BSL entry pattern to TEST and /RST, but I don't know how well that would work at fast speeds (although I'm not sure it has to be fast).

    SBW TEST line is only output, but RESET is bidirectional. All related to SBW / JTAG can be found in slau320 MSP430 Programming With the JTAG Interface.

    AFAIK, USB - UART bridges are not fast enough for SBW entry sequence / shiftings. Situation with old PC's with real serial / parallel hardware port is another story, and first TI FET430PIF (http://www.ti.com/tool/MSP-FET430PIF) was connecting to parallel port. Long time ago, when I was entering to MSP430 world, I made JTAG / SBW flasher that was connecting to parallel port. Later, I made some simple test for comparing switching speed between bridge and real hardware UART...

      

    George Hug said:

    So I need to do more research into TI's JTAG command line flasher and USB driver. I don't have high hopes that the flasher could be used as is, but maybe the source is available somewhere. My memory is that the third party devices from Elprotronics and Flying Camp Design are all BSL flashers, but I will double-check that. If anyone has any suggestions, let me know.

    You will not find much inside MSP_Flasher source. USB driver is irrelevant here. You can find all inside open source MSP Debug Stack (http://www.ti.com/tool/mspds).

    For making SBW master (flashing only for 2xx, based on slau320), can be used bridge chip with low cost G2xx member (as master) or entry level 5xx device with USB hardware module (as master) without bridge chip. Mounted on very small PCB, for few $. I don' know if there is another (more simple / cheaper) way for do it.

    George Hug said:
    I still need to find the mysterious Kurt, the author of mspfet.exe, whose website used to be:

    kurt.on.ufanet.ru

    and who has already done this.

    Kurt's version is just another (or same) MSP-FET430PIF. You can compare schematics by yourself. It is connecting to real hardware parallel port, so it is irrelevant.

  • I spent several hours with slau320 this afternoon, and had not realized how complicated and "low level" JTAG is.  I think you are correct that the JTAG process is too much for a USB-to-UART module to handle.  So it looks like what I wanted to do won't work.  Well then it's no mystery why all the JTAG programmer devices use a dedicated processor as the master.  But I don't think that would be practical for what I need.

    I don't understand your comment about an "entry level 5xx device with USB hardware module (as master) without bridge chip".

    The only thing I've ever seen of Kurt's is a 2009 version of mspfet.exe.  I've never seen anything else that may have been on his site.  It appeared to provide both BSL and JTAG flashing, but you are saying that his JTAG required the use of a hardware port.  If so, then I agree that his program wouldn't be helpful.

    It's too bad about the mass erase problem on BSL, because we know BSL does work with just a bridge chip.  I'll talk to the others involved about the jump table idea and see what they think.  If the processor is going to be soldered in, or surface mount, then the jump table may be workable after all since replacing the chip would be a rare event.

    I really appreciate your help with this.  You obviously are experienced in this material.  Thanks for taking the time to set me straight.

    One final clarification.  It appears that BSLDEMO2 and its relatives all require TI-TXT for the new firmware and the BSL password, not Intel hex.  Is that correct?   Is there a script for Windows that you like that converts Intel hex to TI-TXT?

  • George Hug said:
    It's too bad about the mass erase problem on BSL

    You have option to use custom BSL to solve this problem.

  • In the G2553, BSL is in ROM, not in flash. So my understanding is custom BSL would not be an option for this part.

    Edit:  But perhaps it would.  Thanks for the reference.

  • George Hug said:
    In the G2553, BSL is in ROM, not in flash. So my understanding is custom BSL would not be an option for this part.

    It is still an option. - When you have custom BSL, you can have custom entry sequence into your custom BSL. Usually it is some " BSL entry password" which shall be sent during first second(s) after reset - if your application can afford some delay after reset. Otherwise you can implement simple GPIO pin (jumper) check.

  • Yes, slaa450 was interesting. For this project, we are making full use of the info segments already, so a custom BSL located there probably isn't a good choice this time. But, what's particularly interesting is that if you aren't using the info segments, even the lowly G2231 could have a BSL. And I guess the BSL code could even be located in one of the main flash segments if you have at least 512 bytes not being used.

    Thanks very much for the heads up.

    I understand that the custom protocol is so simple that it could be done with a terminal program on the PC side, at least if you had the firmware to be flashed already in a binary file, but do you know if anyone has written a program that would perform the operation automatically based on command line parameters, including the parsing of TI-TXT or Intel hex files?
  • I made custom BSL for 2xx devices without ROM BSL and hardware UART. Firmware was packed inside (very small) PC GUI application. But device was flashed 1st time by SBW, to prepare BSL.

    https://e2e.ti.com/support/microcontrollers/msp430/f/166/p/326710/1137900#1137900

  • Thanks. I'll take a look.

**Attention** This is a public forum