On Wed, Jul 4, 2012 at 7:08 AM, Peter Bigot <big...@acm.org> wrote: > I really like the EXP430FR5739 "Fraunchpad", but it has too frequently run > into the "fuse blown" problem when using mspdebug rf2500 load to program it. > I programmed http://dbindner.freeshell.org/msp430/fram_bsl.html into an old > G2211 Launchpad and wired up a cable so resets were easy. I've used this > for months during infrequent periods where I'm doing something with this > platform. > > I've been back on the Fraunchpad for two days, and the reset process no > longer works for me. > > What's more interesting is, it appears the reason it doesn't work is that > the BSL entry sequence doesn't take. I've hooked up a logic analyzer and > verified that the G2211 is holding TEST and #RST low, toggling TEST, then > pulling TEST HIGH, then #RST HIGH, then releasing TEST, all according to > Hoyle (slau319b). Nonetheless, a few microseconds later the FR5739 starts > running its application, long before the G2211 can start the mass erase. > > I then moved all the BSL connections to an old G2231 and checked them under > the logic analyzer. Same entry sequence, followed by a mass erase, and in > this case the command is accepted. So I'm pretty sure the commands are > fine, and that it's the FR5739's behavior that has changed. > > The only two things I can see that are different: > > *) I had added a check in my boot-up code which spins while P4.0 is held > low. I then place a jumper between P4.0 and GND to keep the board from > chatting for the several seconds it takes the Linux ACM driver figures > out how to talk to it. I can then remove that jumper, and ttyACM0 works > fine until the board is unplugged. It's likely I've left that jumper on > during some cases where I programmed the board with mspdebug. > > *) 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. > > Anybody have any ideas? Is this failure to enter BSL symptomatic of a real > "blown fuse" on this platform, possibly caused by that jumper's effect on > GND interfering with some commands mspdebug sent? Is there a way to > connect a standard FET-UIF to this board and reset it?
As a follow-up: I downloaded CCS5.2, which can't see the EXP430FR5739 either. I also grabbed SLAA535, which has a Launchpad app that serves as a USB bridge to BSL, allowing the BSL script tool of SLAU319 to run on a Windows machine, through USB to the launchpad, and execute BSL operations. Per the logic analyzer, it too sends the correct BSL entry sequence. Per the EXPFR5739, it doesn't care. As soon as the #RST goes high completing the BSL entry sequence, a single character 255 is spat out over the TXD line, and the application starts running. I've posted something on E2E, but rarely have success with any deep questions there. 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
