MSP430FR5739 ignoring BSL entry sequence

Peter Bigot said:

… occasionally the MSP430FR5739 tells it the fuse is blown…

Did you change the contents of 0xFF80-0xFF83? Those locations are the virtual “Fuse”.

Peter Bigot said:

…As soon as #RST is raised, the MSP430FR5739 sends 0xFF over the TXD line, then immediately starts executing the program.  …

Executing what program?

Peter Bigot said:

…target is transmitting that 0xFF character (which *might* be coming from the application…

From what application?

Peter Bigot said:

…the UART then is supposed to block until a jumper is removed before using it)…

I think you need to remove two jumpers on the FramchPad board before you invoke the BSL entry sequence. The Txd and Rxd pins of FR5739 are connected to the F1611 chip on that board through jumpers. You do not want that F1611 to interfere with the BSL.

Peter Bigot said:

…Any suggestions for how to resurrect these boards?

Check the jumper settings on the FramchPad board. Use the previously working BSL method. The slaa535 method will not work because there is no parity bit. Alternatively, use this 4762.bsl_bridge.c.doc. This is similarly to slaa533 but has even-parity and is designed to resurrect MSP430 targets.

old_cow_yellow said:

… occasionally the MSP430FR5739 tells it the fuse is blown…

Did you change the contents of 0xFF80-0xFF83? Those locations are the virtual “Fuse”.[/quote]

Yes.  They're part of the interrupt vector space in the memory map provided by TI, and would normally be written with the address of a default interrupt handler.  The data sheet (slas639a) specifies that they are reserved but available for use for regular program code if necessary.

With this clue, I found section 1.13 of the FR5xx user's guide that discusses the electronic fuse.  It appears that lockout without password would occur only with 0x5555 written to both JTAG signature locations.  This is highly unlikely to have happened, since 0x5555 could not have been used as an interrupt address.  The value written to those locations is likely to be:

    ff80:       14 c5 14 c5 14 c5 14 c5 14 c5 14 c5 14 c5 14 c5     ............

Lockout with password may be what's happening in the case of mspdebug, but it's almost as unlikely that 0xAAAA was written to those locations.

In any case, does the content of these addresses affect use of BSL?

old_cow_yellow said:

…As soon as #RST is raised, the MSP430FR5739 sends 0xFF over the TXD line, then immediately starts executing the program.  …

Executing what program?[/quote]

The one that had been programmed before the board stopped responding to JTAG and BSL commands.  It behaves as I described in my post; in addition to the part you quoted, I hadn't mentioned that it also flashes an LED pattern to indicate the jumper needs to be removed before it will proceed.  So I know it's what's running.

old_cow_yellow said:

…target is transmitting that 0xFF character (which *might* be coming from the application…

From what application?[/quote]

Ditto.

old_cow_yellow said:

…the UART then is supposed to block until a jumper is removed before using it)…

I think you need to remove two jumpers on the FramchPad board before you invoke the BSL entry sequence. The Txd and Rxd pins of FR5739 are connected to the F1611 chip on that board through jumpers. You do not want that F1611 to interfere with the BSL.[/quote]

Well, yes.  Both the old dbindner method and the SLAA535 method require that external connections be made directly to the MSP side of the TXD/RXD/RST/TEST test header.  I removed the jumpers, disconnecting the USB side, before making those connections.

old_cow_yellow said:

…Any suggestions for how to resurrect these boards?

Check the jumper settings on the FramchPad board. Use the previously working BSL method. The slaa535 method will not work because there is no parity bit. Alternatively, use this 4762.bsl_bridge.c.doc. This is similarly to slaa533 but has even-parity and is designed to resurrect MSP430 targets.[/quote]

 Jumpers are disconnected from the F1611.  The previous method is one of the ones I mentioned that doesn't work.  SLAA535 may not work eventually because of parity issues, but since BSL entry fails before anything's transmitted that's doesn't appear relevant.  All methods, including the one in your word document, involve external hardware to the 4 relevant BSL pins and don't appear to be any different in this first step of entering BSL.  Logic analyzer traces show the BSL entry sequence being transmitted.  LEDs show it didn't work.  Does your code do something different in that phase?

I expect the clue is what you said about the "virtual fuse".  If there is truly a value that can be written to that space that not only locks JTAG but also disables BSL, that really ought to be noted somewhere.  Is this true?  If so, where is it documented?  If not, we're still trying to figure out why the BSL entry sequence fails.

Peter Bigot said:

In any case, does the content of these addresses affect use of BSL?

OK, I think we have an answer.  I'm filling the area from 0xFF80 because that's where TI told me the interrupt vectors live.  Turns out (section 1.14.3.4 of SLAU272A) there's a BSL configuration tag which controls BSL, which is *probably* somewhere in that memory region.  Also turns out the tag identifier for that block is 0x1C, which happens to be the high 8 bits of the default interrupt handler address.

So it's highly likely that I've programmed in a configuration for BSL that's garbage and incidentally tells the BSL not to pay any attention to the UART interface.

Sweet.  These boards are bricks, but now I know what's going on.

Peter Bigot said:

which is *probably* somewhere in that memory region

Fail.  The BSL reading an invalid TLV configuration block is probably a good explanation for the behavior of the entry sequence being ignored.  But why it's getting a bad configuration is still unanswered:  it's supposed to be around 0x1A00, which is not an area I would have written, and it's not supposed to be possible to change the address, so there is still something hinky going on.

Thank you for describing what you observed.

I knew that the "Flash-based BSL" of FR57xx is in ROM at 0x1000-0x10FF, and the contends are protected but visible. Now I suspect that there is another ROM at 0x1A00 which is not visible (to me). I suspect that the code in this ROM is executed at BOR before anything else. It will examine the contents of Flash and decide if JTAG and BSL are enabled or not. There is a "portal" at 0x1A02 just like the portal for BSL ROM at 0x1002. The password is also DEAD BEEF.

TI is not telling us anything about these things.