Daniel, Kuba, a possible explanation for this problem is that the MSP runs into a condition that resets it almost immediately. After releaseing reset, it takes some time fo rthe JTAG to attach and stop the CPU. Since controlling reset and stopping the CPU are two different JTAG operations which need to be sent by software, the introduction of USB FETs with their longer command latency has increased this 'setup time' significantly. However, thread changes or such on the PC could also cause this on the old parallel port FETs. Now if the program immediately resets, the JTAG interface has no time to set a breakpoint. This usually happens if the program has no or not many variables, so the C startup code executes in short time. If then the start of the program causes a reset immediately, any atempt to establish a JTAG connection may fail.
However, this is not the only possible explanation. Writing a firmware for the wrong MSP can also caus misconfiguration of some hardware that will lock-up the MSP until next power cycle. And since the proramming tools usually make a reset, but no power cycle... (this happened for some 2x devices where a wrong hardware programmed the voltage supervisor to watch an external voltage and trigger a reset) Also, 5x devices (includign the FR5x) have a virtual JTAG fuse. On the F5X devices, it is located in teh same flash segmetn the BSL resides in. It is not easy to accidentally blow it. On the FR, exisitng infor about it is wrong. A correction for the docs is scheduled fo rht enext users guide update, but preliminary info about its location was given in a thread in the TI e2e forum (ti.e2e.com). It is normal FRAM and can be reprogrammed at any time. I'm not sure whether there is some additional protection. > As far as I read this morning about BSL operations, the mass erase deletes > both program and information data. Isn't loss of information data going to > bring me more trouble? :) Yes and no. Only a few devices hold calibration data in the info memory. The 1x family doesn't, the 5x family has it stored in a separate TLV structure. (I'm not sure about the FR5x family - does it have info memory at all? since FRam is random read/write anyway, while flash has segments) Only 2x and 4x family do have calibration info and not all of them. However as Daniel explained, this data is only of limited use. The ADC reference calibration data and temperature sensor data is independent of VCC and available for two temperatures, allowing for a linear interpolation. However, the ADC calibration is only for direct input signals. If you have any circuitry attached, it is better anyway to do your own calibration that calibrates this circuitry together with the ADC. temperature sensor calibraiton data is useful and cannot be easily reconstructed. You'll need to operate the ADC for some time on two fixed temperatures which is difficult to do without the proper equipment. However, some empiric calibration can be done by hand, to get some usable result (you'll need a good external infrared temperature sensor then). For the frequency constants, Eric is right, they are only useful for 3.0V VCC. There is a software available at the TI E2E MSP430 forum that allows easy creation of the required DCO configuration for any frequency by using an external 32768Hz watch crystal or any other high-precision exernal clock source (the slower the better, 10kHz to 100kHz are best suited). > You'll probably want to check this, but I'm fairly sure that a mass > erase won't touch the Info A segment, which is the one containing > calibration data. The other info segments are for user data. Daniel, unfortunately a mass erase erases all INFO segments. Except if INFOA has a separate protection and is locked. But the BSL unlocks the INFOA segment on start, so a mass erase through BSL does erase it, while a JTAG MASS erase doesn't (except if the flashing software explicitely supports it and unlocks INFOA before doing a mass erase) However, it the password is known (it is part of the MSPs interrupt vector table, which is known if you still ahve a copy of the code that rendered the MSP useless) then you can log-in, read INFOA and then do the mass erase. Also, there is a chance that you can establish a JTAG conenction when the BSL has been entered (unless the flashing software triggers another reset) and can do a main memory only erase (or just erase the vector table, which is sufficient) It might be possible to do so by entering the debugger, then start the BSL without doing any action, then make the debugger stop the MSP, manually program the flash controller for segment erase and write to the 0xFE00 segment. (or, in case of the FR, simply fill the vector table area with 0xffff, so the offending cde won't start anymore, or reset the JTAG fuse area) Another thing you could try is cooling the MSP down. Since it runs on DCO at startup, and DCO slows with temperature, this may give JTAG enough time to attach before the offendig code is executed. It helps if it is not really the fuse but a code problem. JMGross ----- Ursprüngliche Nachricht ----- Von: Daniel Beer An: Kuba Gesendet am: 22 Nov 2011 01:04:58 Betreff: Re: [Mspgcc-users] Problems with erasing MSP-EXP430FR5739 and then "Security fuse blown" error On Sun, Nov 20, 2011 at 02:34:05PM +0100, Kuba wrote: > I am new to the list, trying to dive into the world of MSP430 and I > already thank you for the great work around mspgcc/mspdebug. Thanks! > > After playing a bit with the original Launchpad I also purchased the > FRAM experimenters board ( MSP-EXP430FR5739 ) mostly because it has > lots of outputs/peripherals and onboard accellerometer, so I can > extend my play/learntime without making boards myself. > > However, from start I got an error in programming using mspdebug > (newest git version) that the device cannot be erased. I found > somewhere else, that this usually ends in the device actually being > erased but not responding. A solution was to unplug/replug the board > to USB, load the program and run. This worked, though it is pretty > annoying to need to replug the board. > Any idea what causes an after-erase error? > > Worse, though, is that after a number of such programming cycles I > received a message that the "security fuse is blown (error 30)" which > disabled my access to the board alltogether. Problem is, I did not ask > for fuse blow (a probably difficult JTAG procedure?) so how on earth > could that happen? > > This all is happening under linux (mint debian edition). If I try to > debug the board from Windows (CCS 5.1) I simply get message that the > board is not accessible. > > > Is it possible I really blew the security fuse by accident? If so, I > guess my only option is to buy a new board, right? Any other way to > check for that? (from CCS itself perhaps?) Hi Kuba, A few people have run into this problem. I'm not sure what causes it, but it is recoverable if you access the chip via the bootstrap loader and perform a mass erase. Cheers, Daniel ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
