Jonathan Roberts14 said:

Part Number: MSP-FET430UIF

Hi Dennis,

Since I have been unable to use the MSP430F2013 on both of my MSP-EXPFG4618 experimenter boards, I decided to attempt connect to the MSP430FG4618 JTAG interface and loading some sample code onto them, however, as soon as I load the binary, and attempt to run the code, the LCD display stops working and it appears as if I am hitting a breakpoint.

As mentioned, my laptop is running Ubuntu 19.10 and I am using the msp-elf-gcc version 8.3.0.16 compiler and building the TI sample code for this board.

As with the previous experience, attempting to load code onto the MSP430F2013, it is visibly obvious that the MCU is no longer functioning, since, after power-cycling the board, the factory-default code, which normally causes the LED3 to flash, stops working.

In the case of the MSP430FG4618, the LCD no longer displays anything.

In none of these tests which I have carried out, have I attempted to program the flash memory on either MCU.

I now have two boards which are dead and am unable to proceed any further.

I would be most appreciative of your assistance in resolving these issues please.

I have attached the source, object and binary files which I attempted to load onto the MSP430FG4618, in a slac129_lcd.tar.gz archive, for your reference.

Thanks in advance.

Best Regards,

Jonathanslac129_lcd.tar.gz

Ok, I'm a little confused - sorry.  I need to have clear understanding.

You first say that you load code " I decided to attempt connect to the MSP430FG4618 JTAG interface and loading some sample code onto them", but then later you say "In none of these tests which I have carried out, have I attempted to program the flash memory on either MCU.".

To me, "loading" some code means programming the flash memory.

Also, when you power cycle the board is the MSP-FET still connected to the MCU?

Hi Dennis,

I have just written to you by TI internal email to let you know that, subsequent to my last post, I have realized the point which you have raised.

I apologize profusely, since I was not aware that the mspdebug "load" command, was writing directly to on-chip flash.

Further, I assumed that since this was TI example code, that it should just run, but have since surmised that, even though I changed the names of the header files to match those in the msp-gcc libraries, there may be some other tweaking necessary, in order to get code which is written for IAR/CCS to compile and link correctly and thus generate a useable binary.

As mentioned, I still trying to get an EMACS-based build and debug environment running, which has been my primary focus up to this point.

I will continue to study and research this, however, any pointers which you may be able to offer, would be most appreciated.

Apologies and thanks.

Best Regards,

Jonathan

Hi Jonathan,

No problem. :) 

For help with what you are doing with the build and debug environment, try reaching out to our SW_Tools forum.

Hi Dennis,

Thank you. I will take your advice and raise any build/debug-related issues up with the SW Tools forum, and appreciate your continued help in trying to resolve the apparent MSP430F2013 flash corruption issue which I reported.

Thanks and Regards,

Jonathan

Hi Dennis,

I have been working through MSP430 GCC tool build issues with the support staff at Mitto Systems, and now have a fully functional set of tools, including MSP430-ELF-GDB, however, I am still unable to connect to my target, without using MSPDEBUG, which is not a TI product.

I am still stuck with the original problem which I have been discussing with you and have been unable run code on either the MSP430F2013 or MSP430FG4618 on either of my experimenter boards.

I am still also discussing the issue of connecting to my FET/target, using a TI driver, with some of your other support staff and hope to have this resolved soon.

I am also of the opinion that the flash memory on the above-mentioned targets, have somehow become corrupted, as originally reported, and would be grateful of further assistance, to resolve this.

Thanking you in advance.

Best Regards,

Jonathan

Hi Jonathan,

Here is the link to our customer support team.  They can help getting your tools replaced.

Hi Dennis,

As mentioned in my previous message, I have been discussing tools issues with Mitto Systems, for GCC-related tools issues.
They have been very helpful and I have a complete MSP-ELF-GCC toolchain built from the latest source, on my system.

Further, I have held ongoing discussions relating to the CCS, CCS-Cloud and MSP Flasher issues with a support team member, by the name of Ki and sent extensive details of the errors which have been occurring, late last week.

The issue which I initially raised with you has not been resolved, and I am hoping that you will be able to assist me in getting to the bottom of what may have happened, and to recover from the apparent corruption to the flash memory contents of the MSP430F2013 and MSP430F4618 on two experimenter boards.

Thanking you in advance.

Best Regards,

Jonathan

Hi Jonathan,

It has been some time and I apologize, but it has taken me some time to ask around and try to get to the bottom of your issue.

I'm going back to a couple of your earlier comments:

"it is visibly obvious that the MCU is no longer functioning, since, after power-cycling the board, the factory-default code, which normally causes the LED3 to flash, stops working."

So with the debugger attached everything works normally but you cycle power nothing happens? or the code runs a bit then stops working?

When you cycle power is the debugger still attached to the target?

Please create the simplest possible version of your code that only toggles an LED (so you can verify code stops working) and demonstrates this issue.

Please enable and create a map file in IAR.

Please zip your source, .out and .map file and provide to me.

Thanks.

Hi Dennis,

Thank you for following up on this.

In fact, since I have not been able to progress any further due to these issues, my work on MSP430 has stagnated.

In answer to your question:

Dennis Lehman said:

So with the debugger attached everything works normally but you cycle power nothing happens? or the code runs a bit then stops working?

With the debugger attached, using MSPDEBUG (which is the only thing that works at the moment,) after loading the "blink" code, and issuing "run,"  the code appears to run and hit a breakpoint, however, no breakpoint has been set. Therefore, LED does not blink. With the FET tool disconnected, after power-cycling, the LED no longer blinks, indicating to me that the code loaded into flash, has somehow become corrupted.

Dennis Lehman said:

Please create the simplest possible version of your code that only toggles an LED (so you can verify code stops working) and demonstrates this issue.

Since I don't have IAR installed on my computer, so am unfortunately unable to follow this suggestion.

Please see the attached blink.lst, blink.obj, blink.out which were generated using msp430-elf-gcc from blink.c. These were made some time ago.

Thank you for your continued help and support.

Best Regards,

Jonathan

blink.zip

Hi Jonathan,

Your example blink program is very straightforward, the problems you are having don't sound like they are caused by code generation issues.

Have you tried using the TI XDS GDB agent instead of mspdebug? It is included with the msp430-gcc installers available here: http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSPGCC/latest/index_FDS.html

I believe you mentioned in a separate post that you cannot get the CCS desktop client to connect to your MCU so you can debug. Unfortunately I can't really provide any additional help if that's the case, we need to have a starting point where we've observed the hardware working before we can investigate further.

Regards,

Hello Joseph,

Thank you very much for getting back to me.

Unfortunately, I am unable use either the MSP430F2013 or the MSP430FG4618 on either of the two experimenter boards which have, since, as far as can tell, the code on the on-chip flash appears to be corrupted and I don't know how to recover from this.

I have partially given up on MSP430 work at the moment, owing to the issues which I have come up against, however, appreciate your suggestion and will look into the link which you have sent me.

Thank you very much for your help.

Best Regards,

Jonathan

Hi Joseph,

I am running Ubuntu OS and completely rebuilt the msp430-elf-gcc 8.3.0.16 toolchain from source.

============================================================

Referring to the User Guide:

4.7.3.1
Starting GDB Agent
On Microsoft Windows, the GDB Agent is available as either as a small GUI application or on the
command line. On GNU Linux, only the command line version is available.

============================================================

As I understand it, the TI XDS GDB agent which you mentioned, is only available on Windows.

Please let me know if I may have understood something.

Thanks and Regards,

Jonathan

Hi Jonathan,

The GDB Agent is available on Linux but only as a command line application. This has the same functionality as the windows GUI application.

There is no source code for the XDS GDB Agent, but it is provided with the MSP430-GCC installers.

Alternatively you can follow these instructions to download the XDS GDB Agent standalone, and there are instructions for using the gdb_agent_console command line tool on Linux there.

Regards,

Hi Josef,

Thanks for getting back to me with this information.

I am downloading the TI XDS GDB Agent for Linux now and will try it out.

Much obliged,

Jonathan

Hi Josef,

I have installed the TI XDS GDB agent, under Ubuntu 19.10, however, would like to ask you to point me to information about launching it.

I found the following:
==========================================================

Launch the XDS GDB Agent Server

The XDS GDB Agent is found in the folder where the EMUPack is installed. If EMUPack is installed in the default directory, it can be found in the folder C:/ti/ccsv7/ccs_base/common/uscif

Launch the XDS GDB Agent console app:

• Open a DOS command prompt or a Linux or macOS terminal
• Type gdb_agent_console.exe <board-data-file> from ccsv7/ccs_base/common/uscifdirectory
  • For Linux/macOS: Make sure LD_LIBRARY_PATH contains the ccsv7/ccs_base/emulation/drivers and ccsv7/ccs_base/emulation/analysis/bin directories

==========================================================

however, I am not intending to use CCS and I have been unable to find details about how to launch it standalone, and further, what port should be used when using the gdb command:

target remote localhost:portnumber

Please could you point me to the appropriate information, since I could not find any documentation with the installation.

Thanks and Regards,

Jonathan

Hi Jonathan,

Is there an "msp430.dat" file in the XDS GDB Agent installation folder?

You launch the GDB agent like this:

./gdb_agent_console msp430.dat

Then in GDB:

target remote :55000

Note that when you launch the GDB agent it will tell you what port it is running on.

In case you don't have msp430.dat, here is a copy from the MSP430-GCC standalone installer, it is quite simple:

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

Something that occurred to me: Have you ever installed (i.e. using the installer) any TI software? I wonder if missing drivers are the cause of your problems.

Using the CCS or MSP430-GCC installers will install the correct drivers so it's worth trying that if possible.

Hi Josef,

Thanks again for your prompt followup.

I followed your instructions and got the following responses:
=========================================================================
jona@bimbo:~/ti/mspgcc/ti/ccs_base/common/uscif$ ./gdb_agent_console msp430.dat &
[1] 28768
jona@bimbo:~/ti/mspgcc/ti/ccs_base/common/uscif$ CPU Name             Port
--------             ----
msp430              :55000

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

===========================
(In a separate terminal, with MSP-FET430UIF and MSP430FG4618/F2013 Experimenter board connected)

jona@bimbo:~/ti/mspgcc/ti/ccs_base/common/uscif$ msp430-elf-gdb
GNU gdb (jona) 8.1
Copyright (C) 2018 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=x86_64-pc-linux-gnu --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 :55000
Remote debugging using :55000
Remote communication error.  Target disconnected.: Connection reset by peer.
(gdb)
===========================
(back in the first terminal)

msp430               Client connected...Connecting to Target
Couldn't find any connected USB FETs!
Failed to initialize FET on TIUSB port. Aborting.
   MSP430 Error :Could not find MSP-FET430UIF on specified COM port
Connection failed...exiting
===========================

I see you have sent another response and will reply separately.

Thanks and Regards,

Jonathan

Hi Josef,

I do have CCS and MSPFlasher installed on this computer and also have the local agent installation for CCS Cloud, however, have never been able to connect to the target from any of these.

Would you be able to help me confirm that these drivers are installed properly please.

Thanks again.

Jonathan

Hi Josef,

I have received contact from a TI member by the name of Harry Qi, who has been trying to follow up internally with the MSP430FETUIF target connectivity issue. He sent me the attached ZIP file, which includes a script to load a udev rules file.

Although this did not resolve the issue, I believe this may have pointed in the right direction and I would like to ask if you could please offer some further help.

I have attached a ZIP archive containing all of the TI-related udev rules files.

There is one which I renamed to 70-mm-no-ti-emulators.rules.orig, since this was installed previously by one of the installer scripts, because Harry Qi sent me a file with the same name.

I noticed that all of these rules files refer to ttyACM* wheres, when I enter ls /dev |grep USB, it lists ttyUSBx when I plug in the FET tool.

I would be most appreciative if you could assist please.

Thanks and Regards,

Jonathan

1856.rules.d.zip

HI Jozef,

Apologies for spelling your name incorrectly in previous correspondences.

I have received some help from Chester Gillon, who pointed out:

======================================================================
In reply to jonahugh:

jonahugh

Yes, as you can see, the FET tool is being recognized:

=====================================================================

jona@bimbo:~/ti/mspgcc/msp430-gcc-8.3.0.16-source-full/install/opt/msp430/bin$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 010: ID 0930:0227 Toshiba Corp.
Bus 001 Device 004: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 003: ID 04ca:7046 Lite-On Technology Corp. TOSHIBA Web Camera - HD
Bus 001 Device 012: ID 0451:f430 Texas Instruments, Inc. MSP-FET430UIF JTAG Tool
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

I think the issue is that USB  idVendor=0451, idProduct=f430 is used for a MSP-FET430UIF with version 2 firmware. In that case, using a Windows PC to update the MSP-FET430UIF to version 3 firmware may then allow the MSP-FET430UIF to be used under Linux with CCS .
==================================================================

I have been back to Chester, however, he has been unable to help me further, with regard to the correct udev rules for Version 2 firmware.

Please could you send me some details about the udev rules needed for CCS, MSP430-Flasher and also TI XDS GDB agent, to suit the MSP-FET430UIF with version 2 firmware.

I would also like to ask for confirmation as to which udev rules file relates to which application.
As I understand it, 61-msp430uif.rules is for MSP430-FLASHER and 70-mm-no-ti-emulators.rules is for TI XDS GDB agent and 71-ti-permissions.rules is used for CCS, however, I am not sure what 99-msp430.rules is used for?

I have tried various combinations of rules, restarting the udev daemon each time, but no luck so far.

Specifically I have been trying commenting/uncommenting the following:

ATTRS{idVendor}=="0451", ATTRS{idProduct}=="f430", MODE="0666"
#ATTRS{idVendor}=="0451", ATTRS{idProduct}=="f430", GROUP="plugdev", MODE="0666"
#SUBSYSTEMS=="usb", ATTRS{idVendor}=="0451", ATTRS{idProduct}=="f430", GROUP="plugdev", MODE:="0666"
#KERNEL=="ttyUSB*", ATTRS{idVendor}=="0451", ATTRS{idProduct}=="f430", GROUP="plugdev", MODE:="0666"

and using the following to restart udev:

sudo udevadm control --reload-rules
sudo udevadm trigger

also tried:

sudo service udev restart

At this point, I am focussing on trying to get the TI XDS GDB agent and MSP430-FLASHER working, because it is much quicker than trying to start CCS every time I make a change.

Chester also came back with the following response, to the above question:

=====================================================================

In reply to jonahugh:

jonahugh

Please could you send me some details about the udev rules needed for CCS, MSP430-Flasher and also TI XDS GDB agent, to suit the MSP-FET430UIF with version 2 firmware.

I don't have the hardware with me at the moment to test changes to the udev rules.

However, I don't think just changing the udev rules will help since:

a. A MSP-FET430UIF with version 2 firmware enumerates as a /dev/ttyUSBx device under Linux.

b. A MSP-FET430UIF with version 3 firmware enumerates as a /dev/ttyACMx device under Linux.

c. The TI msp430 debug stack supplied with CCS under Windows can communicate with either a MSP-FET430UIF with either firmware version 2 or 3, including allowing a switch between the two firmware versions. Where a downgrade from a version 3 to 2 firmware was to allow use of a MSP-FET430UIF with older tools.

d. With the TI msp430 debug stack supplied with CCS under Linux I have only seen communication with a MSP-FET430UIF with firmware version 3.  

My suspicion is that when CCS support was added for Linux, it only supported a MSP-FET430UIF with the later firmware version 3. Hopefully a TI employee can confirm this.
==============================================================================

Since receiving this response, I went through the msp430-flasher source code and replaced ttyACM with ttyUSB and rebuilt it, however, the target is still not being recognized, and I am not confident that the udev rules are correct.

Any help you may be able to offer, would be appreciated please.

Thanks and Regards,

Jonathan

Hi Jonathan,

jonahugh said:

Apologies for spelling your name incorrectly in previous correspondences.

No problem.

jonahugh said:

Any help you may be able to offer, would be appreciated please.

I'm afraid I can't really provide any further insight, since this is a MSP430 driver issue independent of the MSP430-GCC toolchain.

TI employees will be best placed to help you further.

Regards,