Re: [Mspgcc-users] Problems with erasing MSP-EXP430FR5739 and then Security fuse blown error
I had the same thing happen to one of my FRAM boards. I programmed a Launchpad to invoke the FRAM's Flash Boot-Strap Loader and give the Mass Erase command. It's worked on two boards that I am aware of: Directions and code are here: http://dbindner.freeshell.org/msp430/fram_bsl.html Don -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Problems with erasing MSP-EXP430FR5739 and then Security fuse blown error
On Tue, Nov 22, 2011 at 08:34:49AM +0100, Kuba wrote: Sorry for asking silly questions, but though being an electrical engineer I come from the analog side of the world. I guess cannot achieve the mass-erase using the Launchpad-like FET, right? It has to be done with real JTAG programmer? Even more (mspdebug manual page) from non-USB one? The Launchpad/FET programmers are JTAG programmers (though not general purpose ones -- they're designed to be used with MSP430s only), and you can perform a mass erase using them. The problem you have can't be solved this way though, because of the JTAG fuse issue. The bootstrap loader is an entirely different way of accessing the chip which reads commands and data via a UART interface. Once you've done a mass erase via the bootstrap loader, you should be able to access it again via JTAG (i.e. using the Launchpad/FET). Cheers, Daniel -- D.L. Beer Engineering www.dlbeer.co.nz -- 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
Re: [Mspgcc-users] Problems with erasing MSP-EXP430FR5739 and then Security fuse blown error
Dear Daniel, Thanks a lot! I understand now better how this works. I will try to mass-erase and report to the group later on. Regards, Kuba On Tue, Nov 22, 2011 at 9:02 AM, Daniel Beer dlb...@gmail.com wrote: On Tue, Nov 22, 2011 at 08:34:49AM +0100, Kuba wrote: Sorry for asking silly questions, but though being an electrical engineer I come from the analog side of the world. I guess cannot achieve the mass-erase using the Launchpad-like FET, right? It has to be done with real JTAG programmer? Even more (mspdebug manual page) from non-USB one? The Launchpad/FET programmers are JTAG programmers (though not general purpose ones -- they're designed to be used with MSP430s only), and you can perform a mass erase using them. The problem you have can't be solved this way though, because of the JTAG fuse issue. The bootstrap loader is an entirely different way of accessing the chip which reads commands and data via a UART interface. Once you've done a mass erase via the bootstrap loader, you should be able to access it again via JTAG (i.e. using the Launchpad/FET). Cheers, Daniel -- D.L. Beer Engineering www.dlbeer.co.nz -- 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
Re: [Mspgcc-users] Problems with erasing MSP-EXP430FR5739 and then Security fuse blown error
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
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 -- D.L. Beer Engineering www.dlbeer.co.nz -- 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
Re: [Mspgcc-users] Problems with erasing MSP-EXP430FR5739 and then Security fuse blown error
Hi Daniel, Thanks for the info. That sounds a bit better than the chip replacement (though I will try that if nothing else works, thanks Crazy Casta). Did you come across an instruction to follow this procedure? Can it be done with mspdebug? 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? :) Best regards, Kuba On Tue, Nov 22, 2011 at 1:04 AM, Daniel Beer dlb...@gmail.com wrote: 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 -- D.L. Beer Engineering www.dlbeer.co.nz -- 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
Re: [Mspgcc-users] Problems with erasing MSP-EXP430FR5739 and then Security fuse blown error
On Mon, Nov 21, 2011 at 11:06 PM, Kuba kubaraczkow...@gmail.com wrote: Hi Daniel, Thanks for the info. That sounds a bit better than the chip replacement (though I will try that if nothing else works, thanks Crazy Casta). Did you come across an instruction to follow this procedure? Can it be done with mspdebug? 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? :) INFO is really just set aside flash. It isn't really all that special. At least that is true on the older parts, x1, x2, x5 families. I suspect that is still true with the FR parts but haven't looked. For example what is in one of the INFO sections for the 2618 is calibration constants. But these constants are determined by TI for 3.0V, such and such a frequency, and such and such a temperature. Usable for sure but not necessarily the ambient that one will actually be using the beast at. For example, we are using a 5438a and there are also calibration constants but we can't use them because we are running the chip at 1.8V, 38 degrees F, and 4 MHz. So the constants are crap for us. Bottom line is it depends on what is the INFO area. But most likely it won't hurt you. eric Best regards, Kuba On Tue, Nov 22, 2011 at 1:04 AM, Daniel Beer dlb...@gmail.com wrote: 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 -- D.L. Beer Engineering www.dlbeer.co.nz -- 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 -- Eric B. Decker Senior (over 50 :-) Researcher -- 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
Re: [Mspgcc-users] Problems with erasing MSP-EXP430FR5739 and then Security fuse blown error
On Tue, Nov 22, 2011 at 08:06:13AM +0100, Kuba wrote: Thanks for the info. That sounds a bit better than the chip replacement (though I will try that if nothing else works, thanks Crazy Casta). Did you come across an instruction to follow this procedure? Can it be done with mspdebug? 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? :) Hi Kuba, It can be done with mspdebug (flash-bsl driver), but I haven't needed to do it myself. There is some documentation available from TI about the bootstrap loader (MSP430 Memory Programming User's Guide, I think). You'll also need to check the chip datasheet to see which pins you need for BSL communication and entry. 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. Cheers, Daniel -- D.L. Beer Engineering www.dlbeer.co.nz -- 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
Re: [Mspgcc-users] Problems with erasing MSP-EXP430FR5739 and then Security fuse blown error
Dear Eric, Daniel, I see. Indeed if the INFO section contains only useful data and not critical data, then I can safely erase the device. Sorry for asking silly questions, but though being an electrical engineer I come from the analog side of the world. I guess cannot achieve the mass-erase using the Launchpad-like FET, right? It has to be done with real JTAG programmer? Even more (mspdebug manual page) from non-USB one? Regards, Kuba On Tue, Nov 22, 2011 at 8:32 AM, Daniel Beer dlb...@gmail.com wrote: On Tue, Nov 22, 2011 at 08:06:13AM +0100, Kuba wrote: Thanks for the info. That sounds a bit better than the chip replacement (though I will try that if nothing else works, thanks Crazy Casta). Did you come across an instruction to follow this procedure? Can it be done with mspdebug? 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? :) Hi Kuba, It can be done with mspdebug (flash-bsl driver), but I haven't needed to do it myself. There is some documentation available from TI about the bootstrap loader (MSP430 Memory Programming User's Guide, I think). You'll also need to check the chip datasheet to see which pins you need for BSL communication and entry. 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. Cheers, Daniel -- D.L. Beer Engineering www.dlbeer.co.nz -- 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
Re: [Mspgcc-users] Problems with erasing MSP-EXP430FR5739 and then Security fuse blown error
On Mon, Nov 21, 2011 at 11:34 PM, Kuba kubaraczkow...@gmail.com wrote: Dear Eric, Daniel, I see. Indeed if the INFO section contains only useful data and not critical data, then I can safely erase the device. Not silly at all. How many of us have bricked a device accidentally. Understanding is good and we get there partially by asking questions and sharing knowledge. Sorry for asking silly questions, but though being an electrical engineer I come from the analog side of the world. I guess cannot achieve the mass-erase using the Launchpad-like FET, right? It has to be done with real JTAG programmer? Even more (mspdebug manual page) from non-USB one? Regards, Kuba On Tue, Nov 22, 2011 at 8:32 AM, Daniel Beer dlb...@gmail.com wrote: On Tue, Nov 22, 2011 at 08:06:13AM +0100, Kuba wrote: Thanks for the info. That sounds a bit better than the chip replacement (though I will try that if nothing else works, thanks Crazy Casta). Did you come across an instruction to follow this procedure? Can it be done with mspdebug? 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? :) Hi Kuba, It can be done with mspdebug (flash-bsl driver), but I haven't needed to do it myself. There is some documentation available from TI about the bootstrap loader (MSP430 Memory Programming User's Guide, I think). You'll also need to check the chip datasheet to see which pins you need for BSL communication and entry. 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. Cheers, Daniel -- D.L. Beer Engineering www.dlbeer.co.nz -- 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 -- Eric B. Decker Senior (over 50 :-) Researcher -- 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
[Mspgcc-users] Problems with erasing MSP-EXP430FR5739 and then Security fuse blown error
Hello, 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?) Thanks for help! Regards, Kuba -- 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
