The main problem with the JTAG interface is its slowlyness. Adter the JTAG has reset the device, the device starts running. If the JTAG programmer does not take over control and stops execution before the device enters LPM5 or configures the SVS to enter a permanent reset condition, the interface won't be able to detect the device.
The key is to hodl the device in reset condition permanently from power-up to the immediate beginning of the flash/detections process and NEVER RELEASE IT unless reporgramming is finished. unfortunately, none of the tools is able to do this. They all require the device to be already powered-up and running when they are started. Then a reset is applied (or even not in case of some JTAG programmers) and between identifying teh device and starting the programming, the device is also often released. With the BSL, things are a bit better as the BSL kicks in before any user code is executed. It is still possible to bring the device into a state where it caoont be properly reset when it started once after power-up. This includes reconfiguring the SVS (which isn't reset by a reset) or reconfiguring the reset pin to NMI. The solution would be that the programming tool pulls down RST once started, allows the device to be powered-up with RST low, and then immediately starts the programming cycle, so the device does not have any time to ever execute user code after a power-up. Currently it's a race condition. You'll need to power-up the device after the programming tool ahs been started and pulled RST, but before it continues with the device detection. This is almost impossible to do, so you'll almost always lose this race. I'd consider it not a chip erratum but rather a design flaw in the programming cycle/programming software. If your device is powered from teh USB-FET, the Elprotronic software allows powering down the device and it will switch power on immediately before programming. If you're lucky (I didn't test it myself as I didn't have this kind of problems since I got the USB FET), the timing is good enough to enter JTAG mode before the 'bad' user code is executed. The ATMega BSL works differently - it is active as long as RST is low. So you can manually pull down RST, power-up the device and then start programming with RST still low. There are other things to permanently disable the ATMega device, such as misconfiguring the oscillator fuses. JMGross ----- Ursprüngliche Nachricht ----- Von: Peter Bigot An: GCC for MSP430 - http://mspgcc.sf.net Gesendet am: 20 Jun 2010 16:59:08 Betreff: Re: [Mspgcc-users] GitHub eZChronos okay to flash While this may have been the problem, be aware that there is an undocumented (AFAIK) chip erratum on the CC430. I had programmed some boards to immediately enter LPM5 on boot; at that point, I could no longer use the FET over JTAG. See the threads titled *Cannot access TI MSP Experimenters board * from this mailing list about three weeks ago for potentially related information. We were able to restore functionality using the BSL over a USB port on our development boards. I have not tried to diagnose this further. If you left the watch programmed and running and it put itself into LPM5 after some extended idle period, that may have been part of the problem. It's possible that there's something about the code generated by mspgcc vice IAR/CCS that makes it happen. Or it may have just been your Windows problem all along. Peter
