On Wed, Jul 4, 2012 at 5:48 PM, Daniel Beer <dlb...@gmail.com> wrote: > On Wed, Jul 04, 2012 at 07:08:15AM -0500, Peter Bigot wrote: >> *) I'm using the trunk version of mspdebug, which I see had a commit back in >> March to remove a step thought to make the "fuse blown" error more >> likely. Most of my development on this platform was before that version. >> I did use this mspdebug for the last day or two, and I did have a few >> "fuse blown" issues and successfully reset them with the method above, >> until it stopped working. > > As you've discovered, I don't think that this change really had much to > do with the fuse problem at all. It did appear to be unnecessary anyway. > > Does anyone know if this problem occurs with other programming tools? If > it's an mspdebug-specific problem and anyone is able to capture data > from one of the proprietary tools, I'd be quite happy for them to send > it my way.
To update everybody: It turns out that, though the MSP430FR5739 data sheet says that memory from 0xFF80 through 0xFFFF is for the interrupt vector table and the space from 0xFF80 to 0xFFCC is unused and available for program code, in fact that space is where the BSL and JTAG passwords are stored. The FR5xx devices support an "electronic fuse" based on the JTAG passwords. The information in the data sheet and the material provided to me by TI results in mspgcc generating a 64-entry interrupt vector table, where unused entries are initialized to a default handler. Consequently, when mspdebug programmed an application generated by mspgcc, it set all the passwords, and possibly other information, to the bits that represented that default handler. Not everything is clear, since the description in the user's guide does not match observed behaviors without the highly implausible assumption that either the default handler had an address of 0x5555 or 0xAAAA, or that the BSL code looks for a BSLTAG configuration TLV in that memory instead of down at 0x1A00 where it belongs. TI will be looking into that part later. Since the information about the interrupt vector start came from TI, it's possible that CCS or IAR could have the same problem, but I suspect almost all users of mspdebug are also using mspgcc. So it's likely the "fuse blown" issue was never a problem with mspdebug after all. My Fraunchpad boards are now suitable only for levelling tables, but when the replacements come next week I'm going to prepare an update for the LTS and dev releases that changes the interrupt vector for these chips to start at 0xFFC0. This should leave the BSL and JTAG areas intact without negative impact, since at this time no FRAM chips have more than 32 interrupt vectors. Peter ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
