Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

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.

CCS/MSP430-GCC-OPENSOURCE: gdb_agent_console not working with msp-exp5969 launchpad on Linux

Part Number: MSP430-GCC-OPENSOURCE
Other Parts Discussed in Thread: MSP-EXP430FR5969, MSP430FR5959, MSP-FET, UNIFLASH

Tool/software: Code Composer Studio

The topic is close to this one but I think the Studio Forum is closer to my problem then Networks.

I have CCSv7 and msp-exp430fr5969 Launchpad (eZ-FET). They match ideally and I can load and debug my projects to a target msp430fr5959 MCU. I use msp430-gcc, installed with the Studio.

Now I need to launch the debug session without CCS.

First, the uploading of the program. I installed MSPFlasher and it works fine. It asked to update the firmware of my Lauchpad. Since MSPFlasher is very new (30 of November version), I accepted it and now I burn my target device very well. Try to return to CCS - it loads and debugs programs as well. So the firmware update did not break the Launchpad in any way.

Second, debug. But now I try to launch GDB. I run  gdb_agent_console from msp430-gcc package (6.4.0), in another terminal:

export PREF=/home/user/ti/msp430_gcc

$PREF/bin/gdb_agent_console $PREF/msp430.dat

I see a response

Successfully configured /home/user/ti/msp430_gcc/msp430.dat
CPU Name Port
-------- ----
MSP430 :55000

Starting all cores
CPU Name Status
-------- ------
MSP430 Waiting for client

Now I launch a 

$PREF/bin/msp430-elf-gdb foo.elf 

and in a prompt of gdb insert a command 

(gdb) target remote localhost:55000

The proxy server gdb_agent_console connects to Launchpad and immediately begins to update the firmware! More of it. After "updating" it doesn't work properly. More of it. The try to use the Launchpad with the CCS fails too. Only MSPFlasher restores the firmware and Launchpad may be used again.

What is wrong with gdb_agent_console? Or it's my fault?

The msp430.dat was such:

# config version=3.5
$ msp430
  msp430_drvr=msp430.dll
  msp430_port=TIUSB
  msp430_vcc=3.3
$ /

but I tried to edit it in such a way:

# config version=3.5
$ msp430
  msp430_drvr=/home/user/MSPFlasher_1.3.16/libmsp430.so
  msp430_port=TIUSB
  msp430_vcc=3.3
$ /

Nothing changes.

  • Hi,

    You are correct; the process of updating the firmware in the MSP-FET Debug Probe is automatic and happens automatically. One way to prevent this is to overwrite the msp430.dll from the GCC install. 

    One detail that I noticed is that, after updating, the GDB gets kicked out of the connection and I had to re-connect issuing the same target remote localhost:55000. Check the sequence below:

    GDB said:

    user@host:~/ti/msp430_gcc/bin$ ./msp430-elf-gdb
    GNU gdb (SOMNIUM Technologies Limited - msp430-gcc 6.4.0.32) 7.11
    Copyright (C) 2016 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <gnu.org/.../gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law. Type "show copying"
    and "show warranty" for details.
    This GDB was configured as "--host=i686-redhat-linux --target=msp430-elf".
    Type "show configuration" for configuration details.
    For bug reporting instructions, please see:
    <www.gnu.org/.../>.
    Find the GDB manual and other documentation resources online at:
    <www.gnu.org/.../>.
    For help, type "help".
    Type "apropos word" to search for commands related to "word".
    (gdb) target remote localhost:55000
    Remote debugging using localhost:55000
    Ignoring packet error, continuing...
    warning: unrecognized item "timeout" in "qSupported" response
    Ignoring packet error, continuing...
    Bogus trace status reply from target: QStartNoAckMode+;PacketSize=3f0

    (gdb) target remote localhost:55000
    Remote debugging using localhost:55000
    0x00004400 in ?? ()
    (gdb) set disassemble-next-line on
    (gdb) stepi
    0x00004404 in ?? ()
    => 0x00004404: 35 d0 08 5a bis #23048, r5 ;#0x5a08

    However, I was able to connect using CCS7.3 with the MSP430 Toolchain version 7.4.2 without issues. It asks for a firmware update, but only because it is a newer package version than the one provided with GCC 5.0.0.36.

    In this case I really can't pinpoint a root cause for what you are experiencing. I will notify someone from the MSP team to take a look at this as well - perhaps they have additional ideas.

    Regards,

    Rafael

  • Rafael,

    Thank you for your help! And glad to meet you. A couple of years ago you've helped me already.

    Firstly, I'd like to clarify: can we speak about msp430.dll & libmsp430.so as the equal categories for Windows & Linux OS respectively?

    Next. Can we suppose that the different (but close in time/version/size) libmsp430.so may be substituted? Look here:

    Thu 28 Sep 2017  2402176 bytes ti/ccsv7/ccs_base/DebugServer/drivers/libmsp430.so
    Wed 27 Sep 2017  2402176 bytes MSPFlasher_1.3.16/libmsp430.so

    Fri 07 Jul 2017  2448020 bytes ti/msp430_gcc/bin/libmsp430.so

    Checked with diff program the 1-st and 2-nd libs have not difference. Can I suppose that I'm free to replace the library in msp430_gcc toolchain with the newer one from ccs?  Nope! I try to run gdb_agent_console and it fails

    vpe@tkm ~/ti/msp430_gcc/bin $ ~/ti/msp430_gcc/bin/gdb_agent_console ~/ti/msp430_gcc/msp430.dat
    Error loadinglibmsp430.so : libmsp430.so: wrong ELF class: ELFCLASS64
    Failed to configure /home/vpe/ti/msp430_gcc/msp430.dat: Could not load MSP430 library
    
    

    (there were variants in msp430.dat, showing to libraries in ccs and in Flasher dirs)

    When I return the link to the library dated Fri 07 Jul (the "oldest") from the gcc toolchain - agent begins to execute. And wants to "update" the firmware!

    But your hint about resetting GDB session after update - it works! So I can debug now in CLion. It is good. I cannot see disassembly but the rest is ok.

    So, we have such a problem: msp430-gcc gdb agent wants older firmware (downgrade) in my Launchpad, though it gives me the needed result: to work with CLion IDE. But every single return to CCS or MSPFlasher, if need be, will cause the update of the firmware. After which the agent will downgrade it once again.

    I hope you'll have some answer from MSP team!

    Cheers,

    Yury

  • Yury,

    Iurii Vlasenko said:
    Thank you for your help! And glad to meet you. A couple of years ago you've helped me already.

    Nice to connect back to you. I am glad to have helped.

    Iurii Vlasenko said:

    Checked with diff program the 1-st and 2-nd libs have not difference. Can I suppose that I'm free to replace the library in msp430_gcc toolchain with the newer one from ccs?  Nope! I try to run gdb_agent_console and it fails

    vpe@tkm ~/ti/msp430_gcc/bin $ ~/ti/msp430_gcc/bin/gdb_agent_console ~/ti/msp430_gcc/msp430.dat
    Error loadinglibmsp430.so : libmsp430.so: wrong ELF class: ELFCLASS64
    Failed to configure /home/vpe/ti/msp430_gcc/msp430.dat: Could not load MSP430 library

    The datapath size of both libraries differ. I checked it here and found the libmsp430.so shipped with CCS is now 64-bits while the one built into GCC is 32-bits. A ldd helps with that:

    ldd said:

    user@host:~/ti/msp430_gcc/bin$ ldd libmsp430.so
    linux-gate.so.1 => (0xf7792000)
    librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf7513000)
    libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf74f6000)
    libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf737e000)
    libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7329000)
    libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf730c000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7156000)
    /lib/ld-linux.so.2 (0x56639000)
    user@host:~/ti/msp430_gcc/bin$ ldd /opt/CCS_7_3_0/ccsv7/ccs_base/DebugServer/drivers/libmsp430.so
    linux-vdso.so.1 => (0x00007fffd3ad7000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007faaa8d9d000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007faaa8b80000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007faaa87fd000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007faaa84f4000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007faaa82de000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007faaa7f13000)
    /lib64/ld-linux-x86-64.so.2 (0x00005648a91bf000)

    Iurii Vlasenko said:

    So, we have such a problem: msp430-gcc gdb agent wants older firmware (downgrade) in my Launchpad, though it gives me the needed result: to work with CLion IDE. But every single return to CCS or MSPFlasher, if need be, will cause the update of the firmware. After which the agent will downgrade it once again.

    I hope you'll have some answer from MSP team!

    That is the unfortunate scenario of using two different SW versions with the MSP-FET - its firmware is continuously downgraded/upgraded without control (that is also the statement from the MSP team). Ideally the library supplied with GCC should be updated, but I need to find the correct people responsible for this integration.

    I will return to this thread as soon as I find this information and possibly file a bug report.

    I apologize for the inconvenience,

    Rafael

  • Thanks, Rafael!

    So, I have to wait and hope :)

    My scenario is split now.

    When I edit code, compile it and flash - I use CLion + msp430-gcc + MSPDEBUG as a flasher. The latter works only with eZ430, so my target board is connected to eZ430 programmer. 

    Sometimes, rather seldom, I have to debug step-by-step. I have to flash the program, connect the eZ-FET programmer and I can debug in CLion with gdb_agent_console as a GDB stub. The libmsp430.so is 32-bit, as you have discovered.

    If I ever need a CCS for debugging (for example, with disassembler codes) - I'd had to reflash eZ-FET to 64-bit library. Well, I hope there will be no such a case :)

    Cheers,

    Yury

  • Yury,

    CCS is based on Eclipse, which works well with GDB (thus no need to perform firmware updates).

    You will have to install the CDT GNU support from the CCS App Center as shown in the screenshot below, but it will certainly give you quite a lot of flexibility to perform step debug using the Eclipse GUI. 

       

    Additional details are shown at the reference below - just skip step 2.4 as it is done by the App Center step above. 

    There may be another alternative to rebuild a newer version of the libmsp430.so by using the package MSPDS-OPEN-SOURCE in the link below. I have never done that, but I see it supports Linux.

    www.ti.com/tool/mspds 

    Hope this helps,

    Rafael

  • Yury,

    A new MSP-GCC package was released today. Can you give this a try and see if the firmware switching issue goes away?

    http://www.ti.com/tool/MSP430-GCC-OPENSOURCE 

    Regards,

    Rafael

  • Rafael,

    Sure I can and I want to! Thanks!

    Well, it works. Namely: the NEW gdb_agent_console upgrader my eZ-FET, which, seemingly was downgraded last time. I performed a short command-line debug session with msp430-elf-gdb.

    Then I used MSPFlasher to burn via the same eZ-FET - OK! And the next step was to use CLion to debug with the NEW gdb_agent_console - that goes too, though it has to be tested more profoundly. I have to do some other work until Sunday, so it will hang a little.

    But, overall, I think that the problem is solved. Thank you and MSP430-GCC team!

    Cheers,

    Yury

  • Yury,

    I just noticed also that this release has a 64-bit Linux version, which is probably compatible with the most up-to-date libmsp430.so shipped with other products such as Uniflash and CCS.

    I haven't had time to test all this, but I will do in the first opportunity.

    Regards,
    Rafael
  • Rafael,

    I reported all my results in the ad-hoc created blog