I wanted to also have it readily available for TI’s Code Composer Studio 5.x, or CCSv5.x… I moved the code to CCSv5, but of course when I went to launch the debug session I was greeted with this:
I will warn other users of this sample code that it does not function with this board as intended “out-of-the-box” when compiled in CCS. I haven’t run this to ground entirely, but it has to do with timing of the LCD ‘E’ strobe and/or wait times after LCD commands are issued. The function written by the author uses two _NOP() statements between asserting ‘E’ high and then low. The code functions fine when compiled with MSPGCC. To get it working in CCS, I simply replaced the two _NOP() statements with a 10-iteration delay loop and that seemed to fix the issue. But that’s not what this post is about, so I digress…
So, curiously, I went back to my eclipse setup to see if I could launch a debug session after the FET firmware had been upgraded to V3 by CCSv5. Well, my suspicions were confirmed that it would not launch as-is. So I fiddled around with settings upon settings with no success (note: I have a bad habit of not admitting I should just throw in the towel and move on).
I scoured the internet for helpful advice with no avail, hence the reason for this post, as I hope it helps someone with the same or similar issues. During my exhaustive search I learned here that eclipse Kepler has a new built-in GDB Hardware Debug interface (i.e. no longer is the Zylin CDT eclipse plugin required to setup a debug interface for gdb debugging). So I installed eclipse Kepler and the GDB Hardware Debugging plugin. The look and feel of Kepler is very nice by the way in my opinion. I went about setting up the debug interface the way I usually did previously, tried and tried different settings, but still couldn’t get a successful debug session to launch. Finally I started researching the MSP430.dll and the V3 firmware changes to see what was different because, after all, the CCS debug interface is very smooth, fast and reliable. There is a wiki for the MSP-FET430UIF here, and a plethora of info on the MSP Debug Stack here, which led me to downloading the DLL Developers Package v220.127.116.11, Open Source Release and all the documentation.
I had the notion, what if I just took the old MSP430.dll and HID.dll out of the picture (renamed the files with “_OLD” appended so I could easily revert back) and pasted the new dll’s, MSP430v3.dll and HID.dll, in that directory…? Well, from the file size, it didn’t look like HID.dll had changed, but obviously MSP430v3.dll is new – it’s not even named the same. So I run “cmd” from the Start > run and type the following to see if I get anything different back that what I have seen with the old dll:
It seemed that it wasn’t finding the dll, so I renamed the MSP430v3.dll to MSP430.dll, ran the command again, and low and behold I get the normal response I’m used to seeing. So I go back to eclipse Kepler, double check my gdb server setup (msp430-gdbproxy) and my debug configuration setup (msp430-gdb) and it launched the debug session, breaking at main! I stepped through a few lines of code, set a break point or two, run code, etc. and all seems to be working now using the V3 FET firmware along with a renamed MSP430v3.dll file. I’ll also say code download and stepping seem to be much faster.
Below are some screenshots of my eclipse Kepler gdb server and debug configuration setups if you’re interested in what my settings were. I intend to go back and play around with the debug configuration settings, as I am not certain which ones are absolutely needed. There is a place for “Remote Target” setup in the debug configuration settings under the “Debugger” tab, so I think the “target remote :2000” can be removed from the “Startup” > “Initialization Commands” and placed in the “Debugger” > “Remote Target” setup instead and tick the “Use Remote Target” checkbox, but I haven’t confirmed this yet.