Error loading MSP430FR5994 Launchpad using BSL-Scripter

Hi John

I will set up the hardware to do more research. If you have any update please let me know.

Best regatds
Gary

Gary,

Thanks for looking into this.  Here's more info on what I tried already. 

1.  UART interface using the LaunchPad's MSP Application UART1 and also with a USB-UART bridge module based on FTDI FT232 

2.  Attempted to change the MSP430 clock from 16MHz to 8MHz, and also resetting the UART module.  I did this on the recommendation from SLAU550P:

TI recommends clearing the configuration of any module registers that are used in the BSL application,
because the configuration for the external application can interrupt the BSL application and cause
unexpected behavior.

None of these action changed the symptoms described above and the BSL seems to be responding correctly to the TX_BSL_VERSION, 

When I monitor the UART lines with a logic analyzer, the MAP430FR5994 responds correctly again to the TX_BSL_VERSION command, and the BSL-Scripter log shows that the MSP430 responds with <e3> instead of <80-> to the password, but the logic trace does not show this response at all..

The analyzer trace shows the response to the TX_BSL_VERSION, and approx. 40 ms later I see the sign-on message from my firmware application on the UART Tx (indicating a RESET or errant code execution?)

This occurs on 2 LaunchPads I've tested.

John

I believe similar issues were addressed in this thread:

https://e2e.ti.com/support/microcontrollers/msp430/f/166/p/736686/2776295?tisearch=e2e-sitesearch&keymatch=bsl-scripter%20launchpad#pi320995=1

In the end I think they found success by reducing the clock to 1MHz before jumping into BSL.

George,

Thanks much for that link -- I missed it in my search of E2E.   I followed the recommendations of the post and set MCLK to 1 MHz, but no change in my symptoms--I cannot get the BSL to MASS_ERASE or load firmware.

This is my code now:

	if (strcmp(pMagic, magicString) != 0 ) return -1;
    __disable_interrupt(); // to eliminate echo of chars

    WDTCTL = WDTPW | WDTHOLD;   // Stop watchdog timer
    __bis_SR_register(SCG0); // disable FLL
     CS_setDCOFreq(CS_DCORSEL_1, CS_DCOFSEL_3);  // sets internal DCO range to 8MHz
     CS_initClockSignal(CS_MCLK,  CS_DCOCLK_SELECT, CS_CLOCK_DIVIDER_8); // MCLK is 01 Mhz
     __bic_SR_register(SCG0); // enable FLL
    __delay_cycles(3);
    cf = CS_getMCLK();
    FRAMCtl_A_configureWaitStateControl(FRAMCTL_A_ACCESS_TIME_CYCLES_1);        // Add FRAM wait states for FR5969 running at 16MHz
    /*  This code tries to fix the problem of BSL load failure by resetting peripherals, clocks, etc.
     * to state expected on BSL entry*/
    EUSCI_A_UART_disable(EUSCI_A0_BASE);
    debugTTL_HIGH();
    __delay_cycles(10UL);  // 10 uS at MCLK = 1 MHz
    debugTTL_LOW();

	// jump to Z-area of BSL
      ((void (*)())0x1000)(); // jump to BSL	

And again this is the BSL response:

---------------------------------------------------------
BSL Scripter 3.2.0
PC software for BSL programming
2019-Jan-05 23:25:00
---------------------------------------------------------
Input file script is : F:/Dropbox/Projects/QuSpin/BSL FR5969/BSL_Scripter/FR5969test/script_FRxx_uart.txt
MODE FRxx UART 9600 COM9 PARITY
VERBOSE
	Verbose mode is now on!
TX_BSL_VERSION
	[80] [01] [00] [19] [e8] [62] 
	<80> <02> <00> <3b> <04> <e4> <84> 
	[ERROR_MESSAGE]BSL is locked!
MASS_ERASE
	[80] [01] [00] [15] [64] [a3] 
	<80> 
	[ACK_ERROR_MESSAGE]Unknown ACK value!
DELAY 200
	Delay 200 ms
RX_PASSWORD pass32_default.txt
	Read Txt File  : F:\Dropbox\Projects\QuSpin\BSL FR5969\BSL_Scripter\FR5969test\pass32_default.txt
	[80] [21] [00] [11] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] 
	[ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] [ff] 
	[ff] [ff] [ff] [ff] [9e] [e6] 
	[ACK_ERROR_MESSAGE]Unknown ACK value!
RX_DATA_BLOCK SigGenAn.txt
	Read Txt File  : F:\Dropbox\Projects\QuSpin\BSL FR5969\BSL_Scripter\FR5969test\SigGenAn.txt
	[80] [04] [01] [10] [5a] [45] [00] [4f] [14] [1f] [42] [de] [05] [2f] [83] [05] 
	[24] [2f] [83] [05] [20] [b1] [13] [b8] [1f] [02] [3c] [b1] [13] [28] [23] [4b] 
	[16] [00] [13] [81] [00] [00] [24] [b1] [13] [ac] [24] [0c] [93] [02] [24] [b1] 
	[13] [e0] [11] [0c] [43] [b1] [13] [5e] [14] [b1] [13] [b0] [24] [4f] [14] [92] 
	[83] [8e] [20] [b1] [13] [a6] [16] [b1] [13] [c6] [18] [4b] [16] [00] [13] [32] 
	[d0] [10] [00] [fd] [3f] [ff] [f2] [00] [20] [09] [00] [02] [01] [20] [01] [ff] 
	[f9] [1f] [22] [01] [00] [08] [00] [f2] [01] [ff] [f1] [09] [32] [41] [ff] [e9] 
	[08] [20] [27] [01] [38] [00] [e2] [01] [00] [00] [00] [00] [01] [00] [29] [1f] 
	[20] [01] [00] [19] [08] [22] [01] [00] [02] [03] [a0] [01] [ff] [e1] [18] [22] 
	[01] [00] [02] [02] [a0] [01] [00] [20] [00] [ea] [01] [00] [30] [00] [f2] [01] 
	[00] [20] [00] [c0] [01] [00] [00] [00] [00] [01] [ff] [f0] [01] [21] [01] [00] 
	[00] [00] [a1] [01] [ff] [e1] [08] [22] [41] [00] [38] [00] [e2] [01] [00] [30] 
	[00] [c0] [01] [00] [3f] [ff] [20] [01] [ff] [e1] [08] [22] [01] [00] [40] [00] 
	[e2] [01] [00] [42] [04] [20] [01] [00] [10] [00] [e2] [01] [00] [69] [1f] [20] 
	[01] [00] [59] [08] [22] [01] [00] [02] [06] [a0] [01] [ff] [e1] [18] [22] [01] 
	[00] [02] [05] [a0] [01] [00] [60] [00] [ea] [01] [00] [70] [00] [f2] [01] [00] 
	[60] [00] [c0] [01] [00] [00] [00] [00] [63] 
	<80> 
	[ACK_ERROR_MESSAGE]Unknown ACK value!
	Time elapsed of writing 279 bytes : 0.3467 seconds
	Speed of writing data :0.7859(kB/s)

One unexplained observation I made is that the GPIO pulse I'm generating in the code uses __delay_cycles(10UL) but I measure actually 28 uS.   I'm using driverlib to set up MCLK, and it reports MCLK is 1 MHz so the pulse should be 10 uS instead of 28 uS.

Anyway, this issue is still open for me.

John

Some progress to report:    I integrated into another FR5994 project my code that jumps to BSL programmatically, and now the MASS_ERASE and firmware load works as desired.  

So my hypothesis is that when BSL is entered from the first application, the processor state is causing the BSL to malfunction.   Same code in both applications that follows the recommendations in SLAU550P before jumping to BSL:

1. run the BSL at  MCLK <= 8 MHz 

2. I'm also resetting eUSCI_A0 which I use for serial comms, and this is how I command the app to enter BSL

Still, invoking BSL from one app succeeds while the other app fails.   What am I missing?  

 

All I can suggest is that there's something your code modifies after the processor boots, and that modification conflicts somehow with BSL - something BSL expects to be set to the normal boot state. But I don't know how you find what's wrong. I never had any luck jumping into BSL from firmware other than right after boot - before I've changed anything.

Hi John

I have reproduce the problem from my site and I have reported it to relative team. I will update the result if I get.
By the way can share the code that you have succeed invoking the BSL? I want to run it from my site.

Best regards
Gary

Hi John

I am waiting for the tools team for the feedback but no update yet. Do you have any update from your side?

Best regards
Gary