In the middle of programming the TI Launchpad with the Gamepad Tool, Windows decided it needed to reboot to make the changes (basically installing the USB driver, after it said it was installed and ready to use). This threw an error while updating the device, stopping the process in the middle. The interesting thing is that when I plug the device in, it is recognized as a USB Mass Storage device and I can access files on it, meaning it isn’t truly bricked, but the Gamepad Tool no longer recognizes the board to program it for the driver station. Is there an easy way to recover the device to use as the driver station input again?
Based on your description it sounds like the debugger chip is what was corrupted. The USB mass storage device is what the main processor will look like by default. The first time you update the firmware with the tool it has to update the debugger first, and if this doesn’t update properly the tool will not find the board. I was able to reproduce this on my end, and it shouldn’t be a problem to fix. Try the following:
Open a command prompt (go to Start and type cmd in the search bar).
For 32-bit systems run this command (including quotes):
"C:\Program Files\FRC Gamepad Tool\Tools\mspdebug\mspdebug.exe" tilib --allow-fw-update
For 64-bit systems run this command (including quotes):
"C:\Program Files (x86)\FRC Gamepad Tool\Tools\mspdebug\mspdebug.exe" tilib --allow-fw-update
If it works correctly you will see it load new firmware, and you will also see an error that says something like:
tilib: MSP430_VCC: Internal error (error = 68)
tilib: device initialization failed
At this point you should be able to rescan with the tool and see/program the board.
Thank you! Worked perfectly, and now we have a gamepad!
I am receiving an error while trying to program the Launchpad device.
The error that comes up is:
The programmer encountered an error: Error 5000
Gamepad Tool.vi <ERR>
Programmer didn’t succeed. Check log file for details.
This is the Gampad Tool log file I found.
Any help would be appreciated.
#Date: Wed, Jan 14, 2015 11:32:16 AM
#OSName: Windows 7 Home Premium Service Pack 1
#OSVers: 6.1
#OSBuild: 7601
#AppName: Gamepad Tool
#Version: 14.0f1 32-bit
#AppKind: AppLib
#AppModDate: 2/17/2014 03:30 GMT
#LabVIEW Base Address: 0x30000000
InitExecSystem() call to GetCurrProcessNumProcessors() reports: 4 processors
InitExecSystem() call to GetNumProcessors() reports: 4 processors
InitExecSystem() will use: 4 processors
starting LabVIEW Execution System 2 Thread 0 , capacity: 24 at [3504101536.43405530, (11:32:16.434055329 2015:01:14)]
starting LabVIEW Execution System 2 Thread 1 , capacity: 24 at [3504101536.43405530, (11:32:16.434055329 2015:01:14)]
starting LabVIEW Execution System 2 Thread 2 , capacity: 24 at [3504101536.43405530, (11:32:16.434055329 2015:01:14)]
starting LabVIEW Execution System 2 Thread 3 , capacity: 24 at [3504101536.43405530, (11:32:16.434055329 2015:01:14)]
VI_BROKEN (0): [VI “NI_FileType.lvlib:FT_FileTypes.ctl” (0x02f4e948)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI “NI_FileType.lvlib:FT_FileTypes.ctl” (0x02f4e948)]
this->flags=34611712, compilerError=6
VI_BROKEN (0): [VI “NI_LVConfig.lvlib:String to Config.vi” (0x0309fe60)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI “NI_LVConfig.lvlib:String to Config.vi” (0x0309fe60)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI “NI_FileType.lvlib:Get File Type.vi” (0x0559baa8)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI “NI_FileType.lvlib:Get File Type.vi” (0x0559baa8)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI “NI_LVConfig.lvlib:Save Config File.vi” (0x05526920)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI “NI_LVConfig.lvlib:Save Config File.vi” (0x05526920)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI “NI_LVConfig.lvlib:Typecast Queue to Refnum.vi” (0x03042e88)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI “NI_LVConfig.lvlib:Typecast Queue to Refnum.vi” (0x03042e88)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI “NI_FileType.lvlib:LVFileType.ctl” (0x02f36c08)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI “NI_FileType.lvlib:LVFileType.ctl” (0x02f36c08)]
this->flags=34611712, compilerError=6
VI_BROKEN (0): [VI “NI_LVConfig.lvlib:Close Config Data.vi” (0x055153d8)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI “NI_LVConfig.lvlib:Close Config Data.vi” (0x055153d8)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI “NI_LVConfig.lvlib:Typecast Refnum to Queue.vi” (0x02f460b8)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI “NI_LVConfig.lvlib:Typecast Refnum to Queue.vi” (0x02f460b8)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI “NI_LVConfig.lvlib:Config Queue.ctl” (0x0555d0b8)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI “NI_LVConfig.lvlib:Config Queue.ctl” (0x0555d0b8)]
this->flags=36708864, compilerError=6
VI_BROKEN (0): [VI “NI_LVConfig.lvlib:Get Section.vi” (0x02fc7b60)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI “NI_LVConfig.lvlib:Get Section.vi” (0x02fc7b60)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI “NI_LVConfig.lvlib:Load.vi” (0x0305fe60)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI “NI_LVConfig.lvlib:Load.vi” (0x0305fe60)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI “NI_LVConfig.lvlib:Config Data RefNum.ctl” (0x02f4c628)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI “NI_LVConfig.lvlib:Config Data RefNum.ctl” (0x02f4c628)]
this->flags=36708864, compilerError=6
VI_BROKEN (0): [VI “NI_LVConfig.lvlib:Parse Key Value Pair.vi” (0x030c6dc0)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI “NI_LVConfig.lvlib:Parse Key Value Pair.vi” (0x030c6dc0)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI “NI_LVConfig.lvlib:Remove Quotes.vi” (0x03000380)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI “NI_LVConfig.lvlib:Remove Quotes.vi” (0x03000380)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI “NI_LVConfig.lvlib:New Config to Queue.vi” (0x052179b8)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI “NI_LVConfig.lvlib:New Config to Queue.vi” (0x052179b8)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI “NI_LVConfig.lvlib:Unescape String.vi” (0x02fe0d60)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI “NI_LVConfig.lvlib:Unescape String.vi” (0x02fe0d60)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI “NI_LVConfig.lvlib:Get Key Names.vi” (0x02fb2260)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI “NI_LVConfig.lvlib:Get Key Names.vi” (0x02fb2260)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI “NI_LVConfig.lvlib:Read Key (String).vi” (0x02fc4730)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI “NI_LVConfig.lvlib:Read Key (String).vi” (0x02fc4730)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI “NI_PackedLibraryUtility.lvlib:Get Exported File List.vi” (0x05578ec8)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI “NI_PackedLibraryUtility.lvlib:Get Exported File List.vi” (0x05578ec8)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI “NI_LVConfig.lvlib:Config Data.ctl” (0x05552b10)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI “NI_LVConfig.lvlib:Config Data.ctl” (0x05552b10)]
this->flags=36708864, compilerError=6
VI_BROKEN (0): [VI “NI_LVConfig.lvlib:Get File Path.vi” (0x05565450)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI “NI_LVConfig.lvlib:Get File Path.vi” (0x05565450)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI “NI_LVConfig.lvlib:Parse Config to Queue.vi” (0x03070458)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI “NI_LVConfig.lvlib:Parse Config to Queue.vi” (0x03070458)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI “NI_LVConfig.lvlib:Config to String.vi” (0x055379b8)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI “NI_LVConfig.lvlib:Config to String.vi” (0x055379b8)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI “NI_LVConfig.lvlib:Section.ctl” (0x0555d710)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI “NI_LVConfig.lvlib:Section.ctl” (0x0555d710)]
this->flags=36708864, compilerError=6
VI_BROKEN (0): [VI “NI_LVConfig.lvlib:Open Config Data.vi” (0x03044070)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI “NI_LVConfig.lvlib:Open Config Data.vi” (0x03044070)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI “NI_LVConfig.lvlib:Get Key.vi” (0x03015290)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI “NI_LVConfig.lvlib:Get Key.vi” (0x03015290)]
this->flags=33563136, compilerError=6
stopping LabVIEW Execution System 2 Thread 0 , capacity: 24 at [3504101607.57412430, (11:33:27.574124337 2015:01:14)]
stopping LabVIEW Execution System 2 Thread 1 , capacity: 24 at [3504101607.57412430, (11:33:27.574124337 2015:01:14)]
stopping LabVIEW Execution System 2 Thread 2 , capacity: 24 at [3504101607.57412430, (11:33:27.574124337 2015:01:14)]
stopping LabVIEW Execution System 2 Thread 3 , capacity: 24 at [3504101607.57412430, (11:33:27.574124337 2015:01:14)]
Possible path leak, unable to purge elements of base #0
There should also be a log file generated by the programmer backend. Could you attach any files (except Logs.txt) found at this path:
32-bit Windows:
C:\Program Files\FRC Gamepad Tool\Tools\mspdebug\Logs
64-bit Windows:
C:\Program Files (x86)\FRC Gamepad Tool\Tools\mspdebug\Logs
There are not any files in the
C:\Program Files (x86)\FRC Gamepad Tool\Tools\mspdebug\Logs
directory except Logs.txt (which is zero blocks).
I did a search of C: for all files modified today and did not see any files that would be a log file. (this is how I found the Gamepad log file posted earlier.
What would be the name of the log file?
Whenever the gamepad tool tries to program something it is supposed to generate a log file with the date. The name should be Programmer_Log_<date string>.txt
Where did you find the log that you posted? The gamepad tool was build in LabVIEW, so the error that you posted was generated by LabVIEW and not the tool itself.
You can try to manually program the device from the command line by doing the following:
- Open Windows Command Prompt
- Change directory to (on 64-bit): “C:\Program Files (x86)\FRC Gamepad Tool\Tools\mspdebug”
- type: mspdebug.exe --allow-fw-update tilib “prog …/…/Firmware/MSP430-GamePad-OptionX.hex”
where X is 1 2 or 3 depending on the option you want
This should at least get you rolling with the LaunchPad, though I would like to understand what is going wrong.
Could you also post any extra details about the system you are using to program this (are you running from a VM, 32-bit or 64-bit etc.). Thanks
Here is what happened when I ran the command.
C:\Program Files (x86)\FRC Gamepad Tool\Tools\mspdebug>mspdebug.exe --allow-fw-u
pdate tilib “prog …/…/Firmware/MSP430-GamePad-Option1.hex”
MSPDebug version 0.20 - debugging tool for MSP430 MCUs
Copyright © 2009-2012 Daniel Beer <[email protected]>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
MSP430_GetNumberOfUsbIfs
MSP430_GetNameOfUsbIf
Found FET: COM4
MSP430_Initialize: COM4
FET firmware update is required.
Starting firmware update (this may take some time)…
Initializing bootloader…
Programming new firmware…
25 percent done
50 percent done
75 percent done
100 percent done
100 percent done
Update complete
Done, finishing…
MSP430_VCC: 3000 mV
MSP430_OpenDevice
tilib: MSP430_OpenDevice: Unknown device (error = 5)
tilib: device initialization failed
Is there a way to tell that the firmware has been updated?
I am running this on a Windows 7 64 bit machine.
It is a HP dv7-6b55dx Entertainment PC
It contains the intel Core i5 chip set.
If the firmware updated successfully you should be able to have the driver station recognize the device. Windows will also recognize it in their calibration utility.
Edit: Based on the output it looks like the debugger chip updated fine, but something happened when trying to program the main chip. I’ll see if I can reproduce something similar here.
Edit2: Now that the debugger chip is updated, try running the FRC Gamepad Tool again. Reply back whether it is successful or not.
Edit3: The backend of the Gamepad tool is the same as the backend for Energia, it looks like you may have the same issue that is discussed here (different board, same debugger chip): energia-0101E0012 and msp430fr5969 - Energia - MSP - 43oh
I tried the FRC GamePad Tool again and received the same error.
After this, the Driver Station did not recognize the device. I redid the command line previously given and the device is not recognized by the Driver Station as a Gamepad.
Thanks for your help.
Another quick thing that you can check is that the jumpers on the board are all in the correct positions.
This picture here shows what the default positions should be. Please verify that this is the case on your board, and also make sure nothing extra is connected, and there are no pins shorted on the board.
Lastly and if possible, could you try downloading the firmware using a different machine to see if that will work?
Hmm… OK, I have a couple of these devices and one of them programmed just fine. But, the other one started the program and then died in the middle of the program cycle.
From that point, the device does not show a COM port any longer although the disk drive and the USB Inputs do show up. However, if I scan for the MSP430 in the GamePad tool, it doesn’t show up. In trying to use the mspdebug tool, I get:
MSP430_GetNumberOfUsbIfs
No unused FET found
And the tools exits. Any words of wisdom that you can pass along so I can try to fix this problem?
TIA,
Mike
And you tried the recovery method in post #2?
Yes, we did with the result I listed earlier. I’m going to see if Energia can reprogram the firmware to at least get something going.
Update: Energia could update the firmware to get something on the board again. Now, I can detect it in the Gamepad Tool.
However, when I try to program via the GT, we get:
The program encountered an error: Error 5000
Gamepad Tool.vi<ERR>
Programmer did not succeed. Check the log for details.
Looking at the log I see:
tilib: MSP430_Initialize: Interface Communication error (error = 35)
tilib: device initialization failed
MSPDebug version 0.20 - debugging tool for MSP430 MCUs
Copyright (C) 2009-2012 Daniel Beer <[email protected]>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
MSP430_Initialize: COM8
If I try the technique listed in post 7, I get:
C:\Users\mike>“C:\Program Files (x86)\FRC Gamepad Tool\Tools\mspdebug\mspdebug.exe” --allow-fw-update tilib “prog …/…/Firmware/MSP430-GamePad-Option1.hex”
MSPDebug version 0.20 - debugging tool for MSP430 MCUs
Copyright (C) 2009-2012 Daniel Beer <[email protected]>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
MSP430_GetNumberOfUsbIfs
MSP430_GetNameOfUsbIf
Found FET: COM8
MSP430_Initialize: COM8
tilib: MSP430_Initialize: Interface Communication error (error = 35)
tilib: device initialization failed
Still no joy. My other two work fine. But, this is the one from the KOP.
TIA.
Mike
Update #2:
OK, so I used Energia to program the “blink” sketch and that started working immediately. Using that as a sign that the board was, in fact, living in some dimensional plane, I went back to the GamePad Tool. Still no joy.
However, going back to the command from post #7. the reprogramming via mspdebug worked this time! And, I could disconnect and then reconnect and the Gamepad tool worked the 2nd time around.
So, there appears to be something whacked in a timing or something in the GT that I was able to fix with Energia (in Linux).
I hope this helps others that might go down this path.
Mike
Energia and the Gamepad Tool use the same backend, so if it works in Energia, it should work in the Gamepad Tool as well. I am surprised that it did not take right away. I will see if I can replicate this and follow up, but I am glad you were able to get it working!
Were you using a VM in Linux to run the Gamepad Tool? We have seen an issue if the VM doesn’t know to assign the LaunchPad to the guest OS the update can fail. When you update the debugger chip, the USB drops and reconnects, so if the VM doesn’t grab it, the device doesn’t finish updating.
When the gamepad tool failed, it was running in native WinDoze 7 (64-bit). The launchpad was totally hosed with no USB serial interface available. I ran Energia in Linux to recover. Then verified that both my WinDoze VM (VmWare 11) and my native WinDoze machine could reprogram. For the VM, as long as you have the VM focused when you plug the device in, it defaults to capturing any new devices.
So, it was a bit convoluted, but everything is good again. 
Thanks,
Mike
Just to add another data point to this thread…
Our launchpad had similar issues to those mentioned here. The Gamepad tool did not work at all (always gave the 500 series error without any logfile in the the logs directory). I used the more brute force mspdebug method described in this thread and after doing it twice it worked. I now have the luanchpad responding as a game controller (mode 1).
I now need to have the stidents check the data being sent from it to the driver station and make sure we can see the bi-directional response that we need.
Thanks
Note: The last line should read:
I redid the command line previously given and the device is recognized by the Driver Station as a Gamepad.
The command line procedure worked every time.
That makes a lot more sense, thanks for the update!