Hi,
I'm unable to flash (or even reset) my MSP430-H2618 header board. I'm relatively confident that my MSP430-JTAG-TINY-V2 works, as I flashing, resetting, debugging (single stepping, setting breakpoints) with my MSP430-H1611 works just fine. I also can reset my MSP430-H5438 and my MSP430-H449 (didn't test anything but reset there yet). I have a single jumper at P_IN (nothing at P_OUT), the JTAG cable is connected so that pin 1 of the cable (red wire) connects to pin 1 of the JTAG header (square pad).
Here is the output when trying to flash the MSP430-H2618:
$ mspdebug -j olimex "prog examples/default/bin/olimex-msp430-h2618/default.elf"
MSPDebug version 0.25 - debugging tool for MSP430 MCUs
Copyright (C) 2009-2017 Daniel Beer <dlbeer@gmail.com>
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 10004002
Set Vcc: 3000 mV
Configured for JTAG (2)
Sending reset...
fet: FET returned error code 11 (Could not reset device)
warning: fet: reset failed
Device ID: 0xf26f
fet: unknown device
msg28_data: [0x1a bytes]
f2 6f 07 60 00 00 00 00 00 00 02 13 01 00 f6 1c
89 00 89 00 00 00 00 00 00 00
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
Erasing...
fet: FET returned error code 11 (Could not reset device)
fet: reset failed
The warning about `message C_IDENT3 failed` I also get for my other three MSP430 headers boards, btw. I assume this is to be expected?
Note that while initially detected as MSP430F2618, it later says MSP430F2619. If I try instead with:
$ mspdebug -j olimex --fet-force-id MSP430F2618 "prog examples/default/bin/olimex-msp430-h2618/default.elf"
MSPDebug version 0.25 - debugging tool for MSP430 MCUs
Copyright (C) 2009-2017 Daniel Beer <dlbeer@gmail.com>
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 10004002
Set Vcc: 3000 mV
Configured for JTAG (2)
Sending reset...
fet: FET returned error code 11 (Could not reset device)
warning: fet: reset failed
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
Device: MSP430F2618 (forced)
Erasing...
fet: FET returned error code 11 (Could not reset device)
fet: reset failed
I basically get the same error.
Finally, I build the the current master branch of mspdebug and tried with that with the same result.
Am I doing anything work? Or was I unlucky and ended up with a faulty MSP430F2618 MCU on my board?
Kind regards,
maribu
MSP430F2618 should be supported by the last firmware. It would seem to me it is a problem with mspdebug and its support for that specific chip. My advice is to try our programmer software or any alternative software. If it is possible test with Olimex MSP430 programmer software:
https://www.olimex.com/Products/MSP430/JTAG/_resources/MSP_PROG_GUI_1.3.0.4_CLI_2.0.1.2_DLL_1.0.4.2.zip
Remember to place latest dll files in the main folder of the programmer, I believe it doesn't come with latest firmware:
https://www.olimex.com/Products/MSP430/JTAG/MSP430-JTAG-TINY-V2/resources/OLIMEX_MSP430-DLL_drivers.zip
Thanks for the quick reply. Indeed, running that Windows programmer with the updated DLLs did apply a firmware update to JTAG programmer. And now it seems to work fine with mspdebug.
Interestingly, the classification as MSP430F2619 instead of MSP430F2618 still happens at the last step (and also the warning about the failed C_IDENT3 still is there). Applying
diff --git a/chipinfo.db b/chipinfo.db
index 810486d..abe6858 100644
--- a/chipinfo.db
+++ b/chipinfo.db
@@ -19652,7 +19652,7 @@ const struct chipinfo chipinfo_db[] = { {
.fab = 0x00,
.self = 0x0000,
.config = 0x00,
- .fuses = 0x00,
+ .fuses = 0x01,
.activation_key = 0x00000000,
},
.id_mask = {
@@ -19834,7 +19834,7 @@ const struct chipinfo chipinfo_db[] = { {
.fab = 0x00,
.self = 0x0000,
.config = 0x00,
- .fuses = 0x01,
+ .fuses = 0x00,
.activation_key = 0x00000000,
},
.id_mask = {
does fix that issue. Do you happen to know the correct fuses settings of the MSP430F2618 and the MSP430F2619 or where to find that out, just to confirm that this is indeed the cause of the remaining issue?
Thanks so much for your help.
Here is what I tried to find out whether indeed the fuses in the device DB was not correct:
I updated the latest MSPDebugStack (version 3.15.1.1) from https://www.ti.com/tool/download/MSPDS-OPEN-SOURCE and used this trivial program:
#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;
}
to export the TI device DB to an XML file. In that XML file indeed the fuses of the MSP430F2618 are 0x01 and the ones of the MSP430F2619 are 0x00. Still, the MSP430-JTAG-TINY-V2 reads 0x00 back for the fuses and, therefore, mspdebug identifies the device as MSP430F2619 instead of MSP430F2618.
MMM maybe I don't understand something but how is fuses related to software mixing F2618 and F2619, you can't change device ID with fuses. This is probably some sort of bug in mspdebug and ID numbers it expects from target.
Ok so you updated the firmware vie Olimex MSP430 programmer, but did you try reading or programming your MSP430F2618 target? It should be present in the drop down list, the tool also has some command line interface, so my first recommendation is to use Olimex MSP430 programmer tool to determine whether it is a bug in mspdebug.
Let me know if the issue remains, I will try to test here, it wouldn't be too hard to test since we have a board with 2618:
https://www.olimex.com/Products/MSP430/Proto/MSP430-P2618/
I reported the issue upstream at https://github.com/dlbeer/mspdebug/issues/124
The device ID seems to also contain a field called fuses. E.g. for the MSP430F2618 and the MSP430F2619 the MSP Debug Stack has the following database entries
<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>
I just noticed that getconfigfuses() is not implemented for the Olimx MSP430-JTAG-TINY-V2 driver and for that reason `0x00` is stored in the configuration fuses. So it is indeed a software issue.