MSP430Flasher.exe MSP430F2617 Questions

Hey Stefan,

I've used 430Flasher a lot now (big fan) and I've noticed the same "error".  I quote the word error since it seems to be just verbose noise and should be disregarded.  I mean, if you go to the wiki page, the screenshot they provide as reference has the same message! :-)

As for the second issue, I've seen chip manufacturers use the same ID for two different dies before.  I suspect this isn't the case for you however. Most likely the MSP430.dll needs freshening. 

Update to the newest version and let me know if that did it.

MK

Hi Michael,

I have installed the most recent version of MSP430Flasher.exe v1.2.1 which means I should be using the most recent MSP430.DLL.  When I plug in my MSP-FET430 the Green LED lights up and remains lit, which also indicates the most recent MSP430.DLLv3 is being used according to the FAQ on the following page: http://processors.wiki.ti.com/index.php/MSPDS_Debugger_Up-_and_Downgrade

Please find below the info returned which may give you some more clues as to what is occurring.  I am open to any other suggestions.

/* ---------------------------------------------------------------------------
* UseCase : MSP430Flasher.exe
* Arguments : -n MSP430F2617 -w firmware.hex -v -z [VCC]
* ATTENTION: Default options used due to invalid argument list.
* ----------------------------------------------------------------------------
* Driver : loaded
* Dll Version : 30300006
* FwVersion : 30300006
* Interface : TIUSB
* HwVersion : U 1.64
* Mode : AUTO
* Device : MSP430F2618
* EEM : Level 3, ClockCntrl 2
* Prog.File : firmware.hex (ERASE_ALL, verified = TRUE)
* BSL Unlock : FALSE
* InfoA Access: FALSE
* VCC ON : TRUE
* ----------------------------------------------------------------------------
* Disconnecting from device...done
*
* ----------------------------------------------------------------------------
* Driver : closed (No error)
* ----------------------------------------------------------------------------
*/

Thanks,

Stefan

Hello again Stefan,

This is a successful programming session! If you don't believe me, run a verify command or load a program that toggles an IO to prove it.  like I said before, there's a lot of verbosity in the command window that can be misleading.

The final message provided by MSP430 flasher in the command window is "Driver : closed (No error)" 

Congrats!

MK

I can verify that device has been successfully programmed.  I am happy with the resulting output.  My only concern now is the device being incorrectly identified as an MSP430F2618.  I posted the whole output to show the DLL version, FW version and HW version being used as you originally suspected the DLL needed updating?

Hey Stefan,

I did some digging on these two parts and it seems that flash size is the main difference between the MSP430F2618 and the MSP430F2617.  This likely explains why you can run code as long is it's within the boundaries of the smaller 2617 flash.  If/when you hit that 92k limit, I presume bad things will happen.

That said, I cannot explain why the flasher tool detects an incorrect ID unless - and with all due respect, you #included msp430f2618.h instead of the 2617? I'm not exactly sure how it all works but if you compiled for another target, this may reflect what's going on in 430flasher - it's a minimal tool.

As a last resort, you could always have your code "grab" the device descriptor to really see what's going on. I looked up device descriptor area in the memory map on the 2618 datasheet (page 18) and it is located at 0x010FF-0x01000 in flash.

Finally, have you considered another excellent flash programming tool such as the Elprotronic FET-Pro430? It may give you some more freedom to read data out and may even detect the mismatched target.

Good luck,

MK

Stefan,

you are correct, you should refer to the SLAU320 for getting the device ID. I am trying to contact the developer of MSP430Flasher to let him explain and fix this issue.

Hi Stefan,

The F2617 and the F2618 in fact have the same device ID. Apart from the memory size, these devices are so similar that the MSP Debug Stack (on which the MSP430 Flasher is based) doesn't need to be able to tell them apart. In these cases, the Debug Stack usually returns a generic device name with a placeholder like "MSP430F261x". This is not the case here, as Michael already pointed out, this could be solved by a small update of the MSP430.dll.

The important information for you is that the device you have is in fact an MSP430F2617 and you don't need to worry about MSP430 Flasher treating it in a wrong way.

As for the allegedly "invalid" argument list: This is merely a warning that pops up whenever ANY command line switch has been omitted and MSP430 Flasher uses the default options. In 99.9% of cases this is not an issue at all but it might cause some problems in certain corner cases which is why we remind the user to always provide a full argument list. However I have to admit that the wording could be improved.

Best Regards,

Robert