Hi,

when I connect an Olimex MSP430-JTAG-TINY-V2 to an MSP430F2618 (in the MSP430H2618 header board) I get the following output:

MSPDebug version 0.25 - debugging tool for MSP430 MCUs
Copyright (C) 2009-2017 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.
Chip info database from MSP430.dll v3.3.1.4 Copyright (C) 2013 TI, Inc.

Resetting Olimex command processor...
Initializing FET...
FET protocol version is 20000007
Set Vcc: 3000 mV
Configured for JTAG (2)
Sending reset...
Using Olimex identification procedure
Device ID: 0xf26f
  Code start address: 0x3100
  Code size         : 118528 byte = 115 kb
  RAM  start address: 0x200
  RAM  end   address: 0x9ff
  RAM  size         : 2048 byte = 2 kb
Device: MSP430F2618
Number of breakpoints: 8
fet: FET returned error code 34 (Not supported by selected interface or interface is not initialized)
fet: warning: message C_IDENT3 failed
fet: FET returned NAK
warning: device does not support power profiling
Chip ID data:
  ver_id:         6ff2
  ver_sub_id:     0000
  revision:       07
  fab:            60
  self:           0000
  config:         00
  fuses:          00
Device: MSP430F2619

Note that it is first detected correctly as F2618, but then based on the Chip ID data incorrectly as F2619. When looking at the chipinfo.db, the reason obvious:

	{
		.name		= "MSP430F2619",
		/* ... */
		.id		= {
			.ver_id		= 0x6ff2,
			.ver_sub_id	= 0x0000,
			.revision	= 0x00,
			.fab		= 0x00,
			.self		= 0x0000,
			.config		= 0x00,
			.fuses		= 0x00,
			.activation_key	= 0x00000000,
		},
		/* ... */
	},
	{
		.name		= "MSP430F2618",
		/* ... */
		.id		= {
			.ver_id		= 0x6ff2,
			.ver_sub_id	= 0x0000,
			.revision	= 0x00,
			.fab		= 0x00,
			.self		= 0x0000,
			.config		= 0x00,
			.fuses		= 0x01,
			.activation_key	= 0x00000000,
		},
		/* ... */
	},

Other then the fuses, the ID data of the MSP430F2618 and MSP430F2619 are identical. And the read fuses match the database entry for the F2619 and not of the F2618.

I used the following patch to use the now native XML export feature of the MSP Debug Stack in version 3.15.1.1 (the chipinfo.db was created from version 3.15.0.1) to double check if there was just an issue:

Add a utility to dump the MSP430 device database
--- a/Makefile
+++ b/Makefile
@@ -121,6 +121,9 @@
 	rm -f $(STATICOUTPUT).a
 	ar -rs $(STATICOUTPUT).a $(OBJS)
 
+dumpdb: dumpdb.o
+	$(CXX) -o $@ $< $(OBJS) $(HIDOBJ) $(LIBDIRS) $(BSTATIC) $(STATIC_LIBS) $(BDYNAMIC) $(LIBS)
+
 $(PCH_COMPILED): $(PCH_HEADER)
 	$(CXX) $(MAKE_PCH) -o $@ $< $(CXXFLAGS) $(INCLUDES) $(DEFINES)
 
--- /dev/null
+++ b/dumpdb.cpp
@@ -0,0 +1,21 @@
+#include <iostream>
+#include <map>
+#include <vector>
+#include <cstdint>
+
+#include "pch.h"
+#include "DeviceDb/Database.h"
+#include "DeviceDb/exportxml.h"
+
+int main(int argc, char **argv)
+{
+	if (argc != 2) {
+		std::cout << "Usage: " << argv[0] << " <OUTPUT_FILE>" << std::endl;
+		return 1;
+	}
+
+	TI::DLL430::DeviceDb::Database().loadDevices("", false);
+	TI::DLL430::DeviceDb::Database().dump(argv[1]);
+
+	return 0;
+}

And I get the same ID data:

	<device>
		<description>MSP430F2619</description>
		<idMask>
			<version>0xffff</version>
			<fuses>0x7</fuses>
		</idMask>
		<idCode>
			<version>0x6ff2</version>
			<fuses>0</fuses>
		</idCode>
	<!-- ... -->
	</device>
	<device>
		<description>MSP430F2618</description>
		<idMask>
			<version>0xffff</version>
			<fuses>0x7</fuses>
		</idMask>
		<idCode>
			<version>0x6ff2</version>
			<fuses>0x1</fuses>
		</idCode>
	<!-- ... -->
	</device>

So if the MSP Debug Stack in version 3.15.0.1 had incorrect fuses data for the MSP2618, it still has the same issue in the latest version - which I consider unlikely.

So I assume that the chip should have a fuses value of 0x1. Do you have idea what the cause of the mismatch in the fuses data could be?

I have to point out that after updating the firmware of the Olimex MSP430-JTAG-TINY-V2 debugging seems to work quite reliable (before updating the firmware even a simple reset didn't work; if you try to reproduce and have the hardware at hands you likely want to update the firmware first).

I could just pass --fet-force-id MSP430F2618, but I really would like to the tool to be able to detect the chip automatically. In fact, I'm working on a PR to let mspdebug allow adding an --expected-device <DEV-ID> so that mspdebug refuses to flash when the MCU detected doesn't match what is expected. This allows a build system that both handles building applications and flashing to ensure the correct firmware is flashed.