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.
I have been using the previous programmer for years with our custom PC software to program. I purchased the new MSP-GANG hoping for an easy update. I followed the directions on page 73 of the guide. I copied over Gang430.dll, Gang430.ini and MSP-GANG.dll to the program directory. Using the new MSP-Gang I get the error #23 about failed MCU Initialization.
Is there some step I am missing?
Thanks,
Hi Matt,
Thanks for posting. For your custom PC program, is it written in C or some other language? In addition, when you did your test, did you also rebuild your software with it pointing to/including the new Gang430.dll etc instead of the old version? We include also some examples for using the wrapper DLL with the MSP-GANG software installation that you might find helpful - look under MSP-GANG/Examples/Wrapper to find some C and C++ examples using the wrapper DLL.
Regards,
Katie
Hi Matt,
Thanks for doing that test! That indicates that it is likely not just a software issue with using the wrapper DLL, or else the MSP-GANG GUI should have worked. It is more likely that there is a hardware connection issue.
Can you provide the following information so that we can help debug your issue:
JTAG connection questions:
Signal path questions:
The reason I'm asking these types of questions, is that there is a limit on the maximum length of the signal path between the MSP device and the MSP-GANG for reliable operation (see www.ti.com/lit/pdf/slau358 section 1.3 there is a note about this).
Regards,
Katie
Hi Matt,
Unfortunately, without knowing the hardware connection setup, it will be very difficult to debug error 23, because that error indicates a connection issue. I know that your hardware was working with the old programmer, so it could be that a setting is wrong when using MSP-GANG compared to the hardware on your board. But for that we will need the information about how the device is powered and what JTAG vs SBW connections are made between the device and the MSP-GANG so that we can choose the correct settings. Please let me know if you'd be able to find the schematic or someone who knows about the design of the board you are trying to program and relevant info about that box you are using between the board and the MSP-GANG.
Regards,
Katie
Hello Matt,
Can you check a couple of things for me? On the GUI, what is the interface option set to? should be SBW.
Just in case, what is the target power supply current set to?
Thanks.
Marc
Thanks for posting the schematic of the connections. Please note that it is possible to post images directly in your posts if you don't want to have to use imgur ().
Note that Marc was off-base - he assumed you were using SBW but your schematic shows you must be using JTAG.
I see that the 14-pin header appears to be mirrored/rotated in the schematic - e.g. it is showing TDO/TDI on pin 14 on your schematic instead of pin 1.
Is the header that you have for the programmer actually keyed, or could the cable be connected in the wrong direction?
I'm also concerned about all this extra circuitry on the RST line. The entry sequence for JTAG/SBW is very timing sensitive and we even recommend a specific R/C pair to go on that line (47k pullup R with no larger than ~1-2.2nF cap to GND) - see the figure 2-1 diagram above (from ) I'd be concerned that the difference could be that the MSP-GANG is more timing-sensitive than MSP-GANG430UIF, and the design of this is already violating the R/C pair we recommend in the hardware tools user's guide for all of our programmers. We can't guarantee that our tools will work with a configuration other than what is in the diagram above, as that is what they are tested with.
Finally, when you mention 3.3V is that being supplied by the MSP-GANG (which is what your pin connection indicates would be correct) or is it supplied by something else (like something in that white box?)
Regards,
Katie
I ended up making the modifications you suggested and I could program it fine with the built in GUI over and over. So that is good.
I did notice that after programming it with our legacy GUI and the new dll files that it seems to blow the security fuse after programming it. Anytime we try to program afterwards we get a Error #23 again. There is no option to even select blow security fuse in our GUI. Any ideas why we are suddenly blowing the security fuse or is there something else going on?
Thanks,
Katie Pier said:When you say you use your legacy GUI with the new dll files - by legacy GUI do you mean a program that your company developed that used the old DLL but has a GUI interface? Or do you mean the old GUI that was previously provided by TI?
Our own program software that used the old DLL with a GUI interface.
Katie Pier said:If it's a custom program that you made - could you tell what program is used (e.g. c++ visual studio, etc) and the sequence of commands used in the software?
C sharp with visual studio I think. Haven't dove into the source yet.
Katie Pier said:After you get error 23, if you try to use the MSP-GANG + the new GUI are you able to get back into the part or no?
No, on every programmer I try after that I get the error.
I connected it to a MSP430 USB-Debug-Interface MSP-FET430UIF to view the secure fuse in their GUI. You can see the first program went through fine because it hasn't been programmed with our custom GUI with new DLLs and new programmer. But when in I put in the device that is non-responsive, aka the one that fails at initialization, I get this.
mattg said:No, on every programmer I try after that I get the error.
I connected it to a MSP430 USB-Debug-Interface MSP-FET430UIF to view the secure fuse in their GUI. You can see the first program went through fine because it hasn't been programmed with our custom GUI with new DLLs and new programmer. But when in I put in the device that is non-responsive, aka the one that fails at initialization, I get this.
If your program (during execution) on MSP430F5435 doesn't write anything to protected BSL flash memory segment where soft JTAG fuse value is located, than this is due to bad code.
Katie Pier said:
In addition, it could just be a bad code load - in that case, the best way to recover a failing part will likely be to use the BSL to erase the device
**Attention** This is a public forum