I have an msp430f2618 on a know working pcb. This layout has been used many times before without any problems. I've programmed this particular board multiple times, then one time I get an error message, "Software caused reset", or something like that, I can't remember it too well, and the debug session fails. The next time and every time after that I get the message, "Error connecting to the target: Could not reset device". I'm using CCSv5.1.0.09000 and an FET430UIF(updated for the current CCS version). I've tried using a different FET(with updated software) and had the same problem. Since the FETs were updated I have been able to program multiple MCUs.
This problem happened to the first board and I tried getting it to program again with no luck. I was able to program a different board using a different project with each of the FETs. When I went back to the broken board, it didn't matter the project, it still had the same error. I created a new project and placed the "broken" code in it and it worked with no problem on a new board. I programmed this new board through out the day and just now the same thing happened, "Error connecting to the target: Could not reset device".
I put a meter on the reset pin. It's pulled high through a 47k resistor to Vcc(3.3V) and reads 3.1V. Leaving the probe on there and trying to program, I see the reset pin try to reset and goto 2.6V, then jump right back to 3.1V. I've been looking around all day and haven't found any definitive answers.
From my searching I have a few thoughts.
Is the JTAG fuse blown? I've never needed to blow one before and I'm not sure of the error message I'd see.
Is there some really bad software on there that is causing a reset as soon as it's run and will never release the reset pin? If so, how can I erase the flash?
Thanks,
Greg
Greg KoehlerIt's pulled high through a 47k resistor to Vcc(3.3V) and reads 3.1V.
Greg Koehler I see the reset pin try to reset and goto 2.6V, then jump right back to 3.1V.
Greg KoehlerIs the JTAG fuse blown?
Greg KoehlerIs there some really bad software on there that is causing a reset as soon as it's run and will never release the reset pin?
For these cases there are three possible solutions. First, lower the reaction time between reset and JTAg attach. This can be done by using a dedicated flashing software isntead of the (slower) IDE. Such as the Elprotronic tool.It may also help to restart the PC, so the USB devices will re-enumerate. USB has a large latency die to the stack. And the order in whcih devices are detected, removed, detected again makes a small difference which might be the improtant change.
A second way is to build a hardware that keeps RST low after power-up until the an external reset signal is detected. This will prevent the malfuncitoning code to be executed as soon as power is applied. Would work well for the SVS problem and in addition to the latency-reduction in teh first solution.
Third way is to use the bootstrap loader feature (see BSL keyword in the forum and MSp docs). Since it is triggered by hardware, the application code won't execute after reset. It does, however, not help in case of the SVS problem, unless you combine it with the RST-hardware above (to prevent code execution immediately after power-up). Using the BSL, you can erase the offending software (and even upload a new one).
_____________________________________Before posting bug reports or ask for help, do at least quick scan over this article. It applies to any kind of problem reporting. On any forum. And/or look here.If you cannot discuss your problem in the public, feel free to start a private conversation: click on my name and then 'start conversation'. But please do so only if you really cannot do it in a public thread, as I usually read all threads. And I prefer to answer where others can profit from it (or contribute to it) too.
I was able to erase the flash using dedicated programming software ( I used Elprotronic as suggested) and now CCS will work again. I didn't realize how slow CCS is when programming.
I was looking at the code that was causing the problems and it may be related to the size of the code. I changed the printf support from full to minimal, which reduced the code size from 13772 bytes to 8032 bytes. The problem seemed to go away. That code size was from the .text section. Does the printf library with full support put code anywhere else besides the .text section?
As a side note and not really important now, but I re-measured the reset line and I must have had a level shift on because the line measure 3.29V when pulled up and 2.9V when the it was trying to be pulled low.
Greg Koehler I didn't realize how slow CCS is when programming.
Greg KoehlerDoes the printf library with full support put code anywhere else besides the .text section?
Greg Koehler 2.9V when the it was trying to be pulled low
You are right about the reset line, I was using a digital meter. Now that you mention the latency and interpolation, I don't know why I used a DMM instead of the o-scope sitting next to it on my desk.
I've been digging most of the day into this and found one file that seems to cause the problem. The .cproject file has some differences between a working and non-working build. I hastily was going through the compares to see what had changed and did not backup the broken .cproject file before overwriting it. The once broken project now works. I did notice that with the same source code in the two different projects produced 2 different sized out files. The broken one being about 5k larger. The .cproject file contains all the build settings and before I did a copy, I went through each property window in CCS project properties and compared the two projects. They were the same, but the .cproject files were still different.
Thanks for your help in bringing the msp's back to life.
-Greg
Greg Koehler I did notice that with the same source code in the two different projects produced 2 different sized out files. The broken one being about 5k larger.
Well, without the original bad project file, it's all plain guessing.
The important thing is that you got it sorted out. Broken hardware is a bad thing, but even worse if you don't know what has broken it.
I just had a very similar problem. My code seems to have an error that prevented the debugger from connecting to the device (tried CCS and IAR). I tried all I could find in this forum, what eventually worked for me was:
1) Import and compile a simple example like the one in "\ccsv5\ccs_base\msp430\examples\example projects\msp430x2xx C Example" while generating binary-format files as described here: http://www.ti.com/lit/ug/slau157x/slau157x.pdf
2) Rename the output file msp430x2xx to msp430x2xx.txt and copy it to the MSP430Flasher folder (downloaded from http://processors.wiki.ti.com/index.php/MSP430_Flasher_-_Command_Line_Programmer)
3) Use MSP430Flasher_1.2.1 to program the device over command line "MSP430Flasher.exe -n MSP430F2618 -w "msp430x2xx.txt" -v -z [VCC] -e ERASE_ALL"
After that step the simple LED blink code was running and I was able to connect with the debugger from CCS again.