MSP430 Programming / Dumping

[ddcc]

I'm trying to repair some test equipment with an embedded MSP430F437 microcontroller, which has a partially corrupted flash. Unfortunately, it seems that this device is fairly difficult to interface with. My understanding is that for this target, the 2-wire Spy-Bi-Wire interface is not supported, so I have only two options: either the 4-wire JTAG-like interface (if the protection fuse has not been blown), or the embedded UART-based BSL bootloader, which requires a password.

Although the 4-wire interface is JTAG-like, apparently I don't have any equipment that can interface with it. Both my Segger J-Link and TL866 don't support MSP430 devices, and my LaunchPads (MSP-EXP430G2 and MSP-EXP430FR5739) can only do 2-wire Spy-Bi-Wire programming. The official method is to use the MSP-FET430UIF, but $115 is too expensive for a one-off tool that I may not even be able to use, if the fuse is blown. Are there any other options?

[josip]

Only device from 4xx family with SBW is F41x2. If JTAG fuse is blown, only way to access device is UART BSL. I am not familiar with that part, but for 2xx family devices that I was working on, BSL access in a case of unknown password will do mass erase and info A segment with calibrated data (DCO and ADC constants, and maybe something else) will be lost.

MSP-FET430UIF is stone age device, old and slow. MSP-FET is way to go with full JTAG interface.
http://www.ti.com/tool/MSP-FET

If JTAG fuse is blown and you have original firmware image file and info A dump for this device, than everything can be done by UART BSL. If JTAG fuse is not blown than everything can be done by MSP-FET. There are no other options. 

[andersm]

Could the GoodFET work? It's open source, and costs about $50 prebuilt.

[josip]

Could the GoodFET work? It's open source, and costs about $50 prebuilt.

It is simplified MSP-FET430UIF copy, and used MSP-FET430UIF can be found for the same price. Today, MSP-FET430UIF and MSP-FET are open source (hardware and software).

There are also UIF Chinese clones for 30$.
https://www.ebay.com/itm/112472863311

If cost is a most relevant thing, than for simple checking if JTAG fuse is blown or not, can be used (simplified) open source replicator code with any MSP430 as host (I done it 10 years ago with F2xx as hardware base).

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

Or msp-debug on Pi or similar hardware.

https://forum.43oh.com/topic/10035-4-wire-jtag-with-mspdebug-and-raspberry-pi-gpio/

[Peabody]

Perhaps I don't understand the problem, but the SLAU319 pdf says in Section 1.2 that the F437 can be programmed via BSL with the BSLDEMO software.  That's a Windows command line utility.  All you would need is a USB-to-Serial converter module and its driver, something like the CP2102 or one of the FTDI parts, and a way to connect to the right pins.

I believe the F437 has dedicated JTAG pins, which means you would need the signaling pattern described in Section 1.3.2.  The latest version of BSLDEMO from TI has an option to invert the DTR and RTS lines coming out of the adapter to get the polarity right, but if that doesn't work, I have a version that lets you invert the lines individually.  You would need to run the program without connecting to the F437, and see on your scope whether the pattern on DTR and RTS is correct.  Just make sure the adapter you get brings out those two lines.

Then Table 19 gives you the Tx and Rx pins used by BSL.

The big problem with using BSL is if you don't have the right password, it will erase the entire chip, including calibration data, and effectively destroy it.  So make sure you know what the vector table contains, and have that in a TI-TXT password file to include in the command line.  Also, if you're flashing new firmware, that has to be in TI-TXT format too.

I'd suggest you take a very good look at SLAU319, and maybe practice with a cheap DIP part like the MSP430G2553 (after using JTAG SBW to save a copy of its INFOA in case you erase it).

I realize that BSLDEMO is old, and officially deprecated by TI, but they continue to update it, and you don't have to buy expensive gear to make it work.

Oh, and I also have a VBScript that converts Intel-hex to TI-TXT.  All of my stuff is available on Github.  It was written with the G2553 in mind, but it should be the same except for the initial signaling pattern.

https://github.com/gbhug5a/MSP430-BSL

[josip]

All you would need is a USB-to-Serial converter module and its driver, something like the CP2102 or one of the FTDI parts...

There is no need for USB - UART module / driver because ddcc have MSP430G2 LP that can be used as BSL hardware base.
Launchpad-Based MSP430 UART BSL Interface http://www.ti.com/lit/an/slaa535a/slaa535a.pdf

But I guess that BSL password / vector of original firmware is unknown.

[Peabody]

All you would need is a USB-to-Serial converter module and its driver, something like the CP2102 or one of the FTDI parts...

There is no need for USB - UART module / driver because ddcc have MSP430G2 LP that can be used as BSL hardware base.
Launchpad-Based MSP430 UART BSL Interface http://www.ti.com/lit/an/slaa535a/slaa535a.pdf

But I guess that BSL password / vector of original firmware is unknown.

I've never tried that, but it looks like it should work.

But if he does use a USB module, he must remember to set the COM port to 8E1.  Also, if using a module, it looks like the latest BSLDEMO version (2.02), with the inversion option enabled, will produce the correct polarity for his F437.  I assume the slaa535 setup handles all that automatically.  The latest BSLDEMO.exe is in the Deprecated folder here:

http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSPBSL_Scripter/latest/exports/MSPBSL_Scripter_win.zip

[ddcc]

Yes, the main problem is that I need to dump the firmware, so I don't see any point in touching the BSL since I don't have the password. I saw application note SLAA535 about using a LaunchPad as a BSL bridge, and based on SLAU319, the newest BSL version that should be on this chip is 1.60, which it seems may not support forcing mass erase on a bad password entry. Nevertheless, trying to guess the password would be a last resort, so I'd rather start with the 4-wire interface first.

I'm just mostly annoyed that despite having a fully functional JTAG probe, I essentially need to bit bang out JTAG (e.g. with a LaunchPad, over GPIO, or some other tool) in order to interface with the MSP430. Ideally, there'd be a way to use the J-Link with msp-debug or something similar, but I haven't been able to find anything.

MSP-FET430UIF is stone age device, old and slow. MSP-FET is way to go with full JTAG interface.
http://www.ti.com/tool/MSP-FET

Oops, I meant that the MSP-FET is $115, which is a bit too expensive.

There are also UIF Chinese clones for 30$. https://www.ebay.com/itm/112472863311

I saw the listings on eBay; do they work like the actual programmer? Or do the device drivers and development tools (e.g. CCS) need to be modified to work with them?

If cost is a most relevant thing, than for simple checking if JTAG fuse is blown or not, can be used (simplified) open source replicator code with any MSP430 as host (I done it 10 years ago with F2xx as hardware base). http://www.ti.com/tool/REP430F

Hmm, the replicator does seem to be an option. I suppose I could modify the code and put it on a LaunchPad to check the JTAG fuse.

Or msp-debug on Pi or similar hardware. https://forum.43oh.com/topic/10035-4-wire-jtag-with-mspdebug-and-raspberry-pi-gpio/

Interesting, didn't come across msp-debug before. I saw a bunch of references to the msp-gcc and msp-gcc4 open-source toolchains, but they are deprecated and irrelevant, so I didn't look much further. Unfortunately, the only embedded Linux board I have is an ODROID, which is both running some network services and has 1.8V logic, so I'd need to build some logic level shifters first.

Could the GoodFET work? It's open source, and costs about $50 prebuilt.

I believe that would also work, though I could get a Bus Pirate for less than the GoodFET.

[rhb]

FWIW msp-debug has worked very well with all the TI dev boards I've tried it with.  Daniel Beer, the author, is very responsive.  You might want to ask his opinion.  He's in Oz as I recall.

The gcc derived MSP403 tool chain is still very much alive.  But it's being supported by TI staff rather than by Peter Bigot.

[josip]

Hmm, the replicator does seem to be an option. I suppose I could modify the code and put it on a LaunchPad to check the JTAG fuse.

You can tray to port Replicator430 (not X, Xv2 or FR) completely to LP with changing JTAG pins to one available on LP. Or you can create empty project, and copy only few needed functions. Basically, you just need to put target device in JTAG mode and test JTAG fuse.

Code: [Select]

//! \brief Reset target JTAG interface and perform fuse-HW check.
void ResetTAP(void)
{
    word i;
   
#ifdef SPYBIWIRE_MODE
...
#else
    // process TDI first to settle fuse current
    SetTDI();
    SetTMS();
    SetTCK();

    // Reset JTAG FSM
    for (i = 6; i > 0; i--)
    {
        ClrTCK();
        SetTCK();
    }
    // JTAG FSM is now in Test-Logic-Reset
    ClrTCK();
    ClrTMS();
    SetTCK();
    SetTMS();
    // JTAG FSM is now in Run-Test/IDLE

    // Perform fuse check
    ClrTMS();
    usDelay(5); // at least 5us low required
    SetTMS();
    ClrTMS();
    usDelay(5); // at least 5us low required
    SetTMS();
#endif
}

static void CheckJtagFuse_JTAG(void)
{
    // perform a JTAG fuse check
    SetTMS();_NOP();_NOP();_NOP();
    ClrTMS();_NOP();_NOP();_NOP();
    usDelay(15);
    SetTMS();_NOP();_NOP();_NOP();
    ClrTMS();_NOP();_NOP();_NOP();
    usDelay(15);
    SetTMS();_NOP();_NOP();_NOP();
}

//----------------------------------------------------------------------------
//! \brief Function to start the JTAG communication
static word StartJtag(void)
{
    // drive JTAG/TEST signals
    DrvSignals();
    MsDelay(10);             // delay 10ms
   
    if(INTERFACE == SPYBIWIRE_IF) {...} else if(INTERFACE == SPYBIWIREJTAG_IF) {...}
    else // JTAG_IF
    {
        SetRST();
        SetTST();
    }
   
    ResetTAP();  // reset TAP state machine -> Run-Test/Idle
   
    if(INTERFACE == SPYBIWIRE_IF) {...}
    else
    {     
        CheckJtagFuse_JTAG();
    }   
    return IR_Shift(IR_BYPASS);
}

//------------------------------------------------------------------------
//! \brief This function checks if the JTAG access security fuse is blown.
//! \return word (STATUS_OK if fuse is blown, STATUS_ERROR otherwise)
word IsFuseBlown(void)
{
    word i;

    for (i = 3; i > 0; i--)     //  First trial could be wrong
    {
        IR_Shift(IR_CNTRL_SIG_CAPTURE);
        if (DR_Shift16(0xAAAA) == 0x5555)
        {
            return(STATUS_OK);  // Fuse is blown
        }
    }
    return(STATUS_ERROR);       // fuse is not blown
}

//----------------------------------------------------------------------------
//! \brief Function to take target device under JTAG control. Disables the
//! target watchdog. Sets the global DEVICE variable as read from the target
//! device.
//! \return word (STATUS_ERROR if fuse is blown, incorrect JTAG ID or
//! synchronizing time-out; STATUS_OK otherwise)
word GetDevice(void)
{
    word JtagId = 0;            // initialize JtagId with an invalid value
    word i;
    for (i = 0; i < MAX_ENTRY_TRY; i++)
    {
     
        StopJtag();               // release JTAG/TEST signals to savely reset the test logic
        JtagId = StartJtag();     // establish the physical connection to the JTAG interface
        if(JtagId == JTAG_ID)     // break if a valid JTAG ID is being returned
        {
            break;
        }
    }
    if(i >= MAX_ENTRY_TRY)
    {
        return(STATUS_ERROR);
    }
                     
    if (IsFuseBlown())                   // Stop here if fuse is already blown
    {
        return(STATUS_FUSEBLOWN);
    }
}

You can use LP USB-UART bridge for log.

[ddcc]

Cool, thanks for the sample code. Just need to find some time to try it, most likely over the weekend.

I'm somewhat tempted to write a Segger J-Link driver for msp-debug using libjaylink, the interface library used by OpenOCD, but that'd be a much larger time commitment.

[Peabody]

@ddcc, I'm curious about what you are hoping to accomplish here.  You said the F437 has partially corrupted flash.  How do you know that?  Also, I assume that if you don't know the contents of the interrupt table, then this isn't your code you're dealing with.  How will you fix the corrupted flash?  How do you know what's supposed to be there?  Sorry if this is obvious to everyone else, but just trying to understand.

[ddcc]

@ddcc, I'm curious about what you are hoping to accomplish here.  You said the F437 has partially corrupted flash.  How do you know that?  Also, I assume that if you don't know the contents of the interrupt table, then this isn't your code you're dealing with.  How will you fix the corrupted flash?  How do you know what's supposed to be there?  Sorry if this is obvious to everyone else, but just trying to understand.

Right, other people have probably been wondering the same thing. Previous versions of this multimeter used a separate microcontroller with an external EEPROM for storing calibration constants, and probably the software version number, model number, and serial number. With the most recent redesign, there is only a single monolithic MSP430, so this data has probably been moved to on-chip flash, most likely the information memory segment INFOA. Unfortunately, I don't know the history of this multimeter, nor how this data was erased, but it doesn't seem like any previous owner ever disassembled it, so it was probably a fluke. And as a non-original owner, warranty service seems unlikely. The multimeter still boots, but just stalls with an EEPROM error at startup, and displays a software version number of zero, so I hope that the code is fine. The calibration manual for another model states that the model and serial numbers can be reprogrammed with the service software over the IR serial cable, but this model doesn't support IR communication (although the pads are present), and the service software doesn't seem to be publicly available. Since the factory needs a programming mechanism, I assume that there's probably a secret button sequence, but without the firmware I have no idea what it could be.

[Peabody]

Thanks for the explanation.  It still seems like a long uphill road to get it back to working.  Maybe there's a forum somewhere related to the meter where you could get some advice.

[ddcc]

Hmm, so I ported the Replicator430 project over to the MSP-EXP430FR5739 board, which ended up being much more of a pain than I expected. I initially started with the MSP-EXP430G2, but then realized that it didn't have enough GPIOs for the JTAG plus LEDs, so I had to switch to a different LaunchPad. After that, I had to disable the target voltage supply, 12-bit ADC, and level shifters, since those are only on the Replicator, and change the system clock to the internal DCO at 24 MHz, divided in half to 12 MHz for ACLK, MCLK, and SMCLK, since I don't have an appropriate external crystal oscillator. The modified source code is up at https://github.com/ddcc/Replicator430.

Unfortunately, this modified version doesn't seem to be working on a test MSP430G2211 chip that was supplied with a LaunchPad. The JTAG ID from StartJtag() is being read as all zeroes, which isn't correct. I'm powering the test chip from the 3.6 VCC on the LaunchPad. And the following logic capture shows what appears to be valid JTAG signaling. Am I missing something?

[bson]

Looking at the trace it seems to try to reset the JTAG TAP chip by holding TMS high for five cycles of TCK.  This doesn't work on all devices (in general, not sure about MSP430 in particular).  Following the reset it pulses TMS to advance the state machine.  At the end it looks like it sets the IRCODE to 0xff, which is BYPASS, which means anything on TDI should repeat on TDO.  This is to test the TAP is in the proper state and responding to commands  It clocks in one TDI = H and expects to see the same on TDO, but doesn't and concludes it's not functioning correctly.  Most likely because it was never reset.  I'd change the code to explicitly pull nTRST instead, for reset.

[ddcc]

Looking at the trace it seems to try to reset the JTAG TAP chip by holding TMS high for five cycles of TCK.  This doesn't work on all devices (in general, not sure about MSP430 in particular).  Following the reset it pulses TMS to advance the state machine.  At the end it looks like it sets the IRCODE to 0xff, which is BYPASS, which means anything on TDI should repeat on TDO.  This is to test the TAP is in the proper state and responding to commands  It clocks in one TDI = H and expects to see the same on TDO, but doesn't and concludes it's not functioning correctly.  Most likely because it was never reset.  I'd change the code to explicitly pull nTRST instead, for reset.

Yeah, in the source  https://github.com/ddcc/Replicator430/blob/master/JTAGfunc430.c, the code explicitly pulses TCK for six cycles (line 212), then moves to Test-Logic-Reset and subsequently Run-Test/Idle. For some reason, it checks the fuse twice (with different timings), once in `ResetTap()` (line 225), and again explicitly in `CheckJtagFuse_JTAG()` (line 637), before calling `IR_Shift(IR_BYPASS)` (line 639). Then, there's actually a third function, `IsFuseBlown()`, which does something else to check the fuse. I haven't checked the programming manual to figure out why all three methods are different, but it does look weird. I think you're right about TRST, I don't see it being set low at any point earlier in the code. Perhaps the I/O translator on the actual board has some different default pin state.

I should have made an update earlier; after I couldn't get this Replicator430 port working over the weekend, I decided it wasn't worth the time to fix, and luckily managed to get a used MSP-FET for cheap. Last night, checking with UniFlash showed that the JTAG fuse is indeed blown, so I plan to connect the MSP-FET backchannel UART to the BSL. But the BSL TXD and RXD pins are being used by this design, so I'll need to reverse engineer the circuit a bit to figure out if I can just connect to them directly, since lifting pins on the LQFP package seems a bit risky.

Unfortunately, it seems that repairing this multimeter will be fairly unlikely, because even though BSL 1.60 doesn't force a mass erase on bad password (https://sourceforge.net/p/mspgcc/mailman/message/19668938/), the size of the keyspace suggests that brute-forcing isn't likely to be feasible (https://travisgoodspeed.blogspot.com/2008/06/msp430-bsl-passwords-brute-force.html). Nevertheless, I figure I might as well give it a shot, and take the opportunity to play around with some VCC or clock glitching attacks as well.

[bson]

Ah yeah, of course, if the fuse is blown it's not going to respond on the JTAG port.