msp430-gdb Back in Business!


Picture

Usually I’m able to figure most things out on my own – but since late yesterday, I have been battling getting my MSP-FET430UIF debugger to work in eclipse after the debugger firmware was upgraded to V3.  I knew there was the option of downgrading, but I knew, I just knew there had to be a way to integrate my existing debugger, upgraded to V3 firmware, with an IDE I favor (eclipse) and the gcc debug environment.  Read the rest of the story after the break…

Well, ladies and gents I was ecstatic when I finally got this to work!  I also hope this wasn’t such a simple solution that it makes it onto hackaday’s fail-of-the-week…  Now, I had been using eclipse Helios with the gcc debug setup on another project when I stepped away momentarily to work a quick-and-dirty dev board setup for the Olimex MSP-169STK.  I did the dev board setup in eclipse, which can downloaded from github here.  It’s just the factory demo sample code that came with the board plus the eclipse project wrappers, compiler and debugger setup.  All went fine in eclipse.  I could compile, launch the debug session and debug the code just fine.  I also verified the sample code worked as intended when running without the debugger.  

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:

Now, I know I had used this same physical debugger with CCSv5 before, and I wasn’t sure what version of FET firmware I had, but I went ahead with the upgrade knowing if all else failed when I went back to gdb that I could always downgrade back to the V2 FET firmware with this process outlined here.  Before I move on, I did complete this task and have posted this same setup for CCSv5 in github here.  Again, just the factory demo sample code for the board, but I took the liberty to clean it up so it is readable to a human being ;-).  

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 v3.3.1.4, 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:
C:\>msp430-gdb –help

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.

Leave a comment

Your email address will not be published. Required fields are marked *