CCS/MSP430FR6047: MSP430FR6047 BSL

Hello Mesut,

we're looking into your problem, and will come back to you later today. Have you check on our BSL landing page about the documentation on our main BSL landing page? There you should be able to find the documents describing the BSL details and potential differences between different families and derivatives.

and FRAM device BSL User's Guide.

Best regards

Peter

Thank you for quick answer

Actually, I took as reference SLAU550T (Revised April 2019) document. I have not a problem with FR6989.

Acording to SLAU550T there is no known bug and there are no differencies between two BSL version.

I reviewed family user guide document but I did not find any trick.

Hi Mr. Spevak

I resolved second problem (reset with BSL) by writing to PMM CTL0 register 0xA5 and 0x04 sequentially in order to trig BOR.

But, first problem (BSL core is not responding to UART after mass erasing operation.) is still contiinue.

Best. regards...

Is there any solution Mr. Spevak ?

Hi Mesut

What's the hardware and software tools do you use and how you connect to the MSP430? Dose the feedback of the password is OK or faild?

Best regards

Gary 

I am using own GUI interface/parser and connecting EUSCI A0 hw with simple PC-MCU RS232 converter.

     PC-GUI cmd                                   MSP430FR6989 Core Response                                MSP430FR6047 Core Response

RX Password (0x11)                                        0x3B 0x00                                                                       0x3B 0x00  

Mass Erase (0x15)                                           All frame : 0x00 (some times 0x00 0x3F)                       All frame : 0x00 (some times 0x00 0x3F)   

Any command (after mass erasing)                 Response is according to command                              There is no any response at all (any byte or any frame)

Two device are responsive to GUI BSL commands before mass erasing. But after mass erasing operation (by writing 0x15 or wrong BSL password), FR6047 is not responsive to UART BSL commands. My GUI is suitable for correct sequence for download new firmware to MCU. I tested it on FR6989 devices.  

I think that there is a bug on FR6047 devices or 00.08.35.B3 BSL version. Mass erasing command so important for downloading new firmware, because, other hand, I must know current firmware on the chip and must know BSL pasword.

I am waiting for your helps...

Hi Mesut,

The BSL under MSP430FR6989 and MSP430FR6047 shall have the same behavior. When we send wrong password through RX_PASSWORD command or directly with MASS_ERASE, the BSL will call mass erase function that is located under bootcode. In the FR5xx and FR6xx, the mass erase execution does not send response. (under UG SLAU550 Section 4.5.1.2 Command Returns and Section 4.5.1.3 Command Returns).

I run the test under MSP430FR5969 (it has same BSL version as MSP430FR6989) and MSP4306047 and track the bytes transmitted on the line.

MSP430FR5969 (initial state device is empty)

C:\Users\a0406885\Desktop\bsl_fr6047_fr5989>BSL-Scripter.exe script.txt
---------------------------------------------------------
BSL Scripter 3.4.0.1

PC software for BSL programming
2020-Feb-11 11:27:02
---------------------------------------------------------
Input file script is : C:/Users/a0406885/Desktop/bsl_fr6047_fr5989/script.txt

MODE FRXX UART COM13 9600
VERBOSE
        Verbose mode is now on!
RX_PASSWORD
        [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]
        <80> <02> <00> <3b> <00> <60> <c4>
        BSL Password is correct!
TX_BSL_VERSION
        [80] [01] [00] [19] [e8] [62]
        <80> <05> <00> <3a> <00> <07> <34> <b2> <14> <90>
        Vendor:[TI] CI:[07] API:[34] PI:[B2]
MASS_ERASE
        [80] [01] [00] [15] [64] [a3]
        [ACK_ERROR_MESSAGE]Unknown ACK value!
TX_BSL_VERSION
        [80] [01] [00] [19] [e8] [62]
        <80> <02> <00> <3b> <04> <e4> <84>
        [ERROR_MESSAGE]BSL is locked!
RX_PASSWORD
        [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]
        <80> <02> <00> <3b> <00> <60> <c4>
        BSL Password is correct!
TX_BSL_VERSION
        [80] [01] [00] [19] [e8] [62]
        <80> <05> <00> <3a> <00> <07> <34> <b2> <14> <90>
        Vendor:[TI] CI:[07] API:[34] PI:[B2]

For MSP430FR6047 (initial state device is pre-programmed, therefore the first password results in wrong password)

C:\Users\a0406885\Desktop\bsl_fr6047_fr5989>BSL-Scripter.exe script.txt
---------------------------------------------------------
BSL Scripter 3.4.0.1

PC software for BSL programming
2020-Feb-11 12:27:17
---------------------------------------------------------
Input file script is : C:/Users/a0406885/Desktop/bsl_fr6047_fr5989/script.txt

MODE FRXX UART COM13 9600
VERBOSE
        Verbose mode is now on!
RX_PASSWORD
        [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!
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]
        [ACK_ERROR_MESSAGE]Unknown ACK value!
TX_BSL_VERSION
        [80] [01] [00] [19] [e8] [62]
        <80> <02> <00> <3b> <04> <e4> <84>
        [ERROR_MESSAGE]BSL is locked!
RX_PASSWORD
        [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]
        <80> <02> <00> <3b> <00> <60> <c4>
        BSL Password is correct!
TX_BSL_VERSION
        [80] [01] [00] [19] [e8] [62]
        <80> <05> <00> <3a> <00> <08> <35> <b3> <35> <9f>
        Vendor:[TI] CI:[08] API:[35] PI:[B3]

Hi

I tried with BSL-scripter application but MCU gives me "Header  incorrect!" error. (verbose mode on)

Let's forget BSL-scripter.exe and turn to my GUI. 

As I said that above, GUI and FR6989 give me succesfull results. 

GUI sequence is below;

1. Select hex file (INTEL formatted)

2. Send mass erase command.

3. Delay a bit

4. Send Rx Password command (0xFF......0xFF)  for unlock BSL.

5. Rx Blocks according to hex file 

6. CRC commad (optional)

7. Write to PMM CTL0 register 0xA5 and 0x04 sequentially in order to trig BOR.

I wonder that while my application runs succesfully on MSPFR6989 device, why does't run with MSPFR6047?

I resolved BSL-stricpter's "header incorrect" problem writing PARITY to MODE line in script input file.

But result is same. BSL is not responsive to any command after mass erasing performed.

Any idea? What might the problem?

Hi Mesut

I sow your input in your CMD file is wrong if you capture all your CMD window above.

You can follow the guide attached 2262.Download_image_BSL.pdf

Hi.

I just renamed script_FRxx_uart.txt as s.txt for writing simplifed.

Originally, file is script_FRxx_uart.txt 

Hi Mesut

That seems this issue related with your hardware. Do you have a MSP-FET in your side?

Best regards

Gary

Yes,

I use part of EXP-FR6989 launch pad emulation tool.

Hi Mesut,

may I ask you about your intentions? Why are you trying to use a LP as a BSL HW. This is not an official tools for BSL. You could use either the MSP-FET or the MSP-BSL Probably you're running into all these issues, as you're not using a HW intended to be used with BSL.

Best regards

Peter

Hi.

I think that I am misunderstood a lot (or I tell wrong)

I have an EXP LP board and I use it only for programming/debugging my own designed circuits via external cables. (Syp-Be  Connecion) . And using Elprotronic Lite FET PRo430 or CCS debugger. OK?

I have two circuits designed by me ; one of MSP430FR6949 and one of MSP430FR6047 based.  

On the UART side; I connect MCU EUSCI_A0 pins  to PC via PL2303 and photodiode based INFRARED adapter and  I tested connection with hyperterminal in 9600 BR. As test result; both of circuit are succesfull at Tx and Rx operation byte and frame (50 byte)  OK?

On the BSL side; I am jumping BSL memory from firmware. My designed GUI could achieve to communicate wit BSL core. And my GUI have erased, unlocked, written new block and restarted FR6989 based circuit. 

BUT................  On FR6047 based circuit, BSL - PC communication no more available after mass erasing. BSL is become unresponsive to GUI calls.

WHAT IS MY INTENTION?

In our project, we are trying to contacless (without any cable connection) upload firmware and track device error. Only contactless infrared uart adapter will use.

I think, I am clear enough..

Best regards...

Hi Mesut,

many thanks for the detailed explanations.

Unfortunately it still does not give us an idea, why the MSP430FR6047 is not responding after the execution of mass erase. What potentially might give us additional indication would be a memory dump of the erased device. The suspicion is, that for whatever reason, something related to the BSL functionality is destroyed at mass erase.

I assume you have still JTAG access to the erased device. So please, could you send us the memory dump of it? Many thanks in advance.

Best regards

Peter

Dump files below. 

JTAG is still accessable  after mass erasing.1856.dump_files.rar

Hi Mesut,

many thanks for the memory information. Unfortunately it is only the main memory. Could you please read out the TLV portion of both, before and after mass erase (001AFFh to 001A00h).

Many thanks in advance.

Best regards

Peter

Hi Mesut,

another question comes to my mind. So the MSP430FR6047 does not respond to BSL anymore, after performing the mass erase. But as the JTAG is still open for programming, could you please try to re-programm the device with the original code, to check whether it works properly on one hand, and on the other hand, if the device would be accessible by BSL again afterwards?

Many thanks in advance.

Best regards

Peter

Hello Mesut,

we have once again tried to reproduce, what you're experiencing on your side, and have performed with an MSP430FR6047 a mass erase using the BSL rocket and a target board for the MSP. We were able to execute the mass erase and also to communicate after the mass erase with the MSP using BSL.

This means, we do not see the issues you're observing. So basically all indicators are pointing so far to your setup, as root cause of the failures. Thus we need to understand perfectly your setup and the actions you're applying.

We though would recommend first getting the BSL communication and flow with a tested environment, means using an official HW tool and SW (BSL scripter) to eliminate at least some of the unknown variables.

Please find here also an outline flow, of what we understood from your descriptions, what should be happening on your side.

1. step is the mentioned SW invoke of the BSL you mentioned. If this is successful, the device will be waiting on the password from the host.

2. Then the host transmits the password and the target MSP should acknowledge this. This seems to be working on your side.

3. Then the host transmits the mass erase command to the target MSP. In this case the target device should only execute the mass erase, but not send a response. Also this steps seems to be working on your side, at least to the extent, that the target MSP is executing the mass erase.

4. In our case with our tool chain and setup, after mass erase, the target device would remain in BSL mode, means does not require a HW or SW invoke of the BSL, but waits again for the BSL password. Keep in mind now the PW has changed due to the mass erase. According to your explanations, this step does not work anymore on your side.

Thus as explained above, we're recommending to eliminate as many differences between your and our setup, to reach a functional setup, and then start adding the necessary modification towards your desired setup, one modification only in each step and test, whether it still works. But the goal should be definitely starting with a setup that works.

If you can provide us more detailed information on your setup we might in addition try to identify some critical details, which might be contributing to the observed problem.

Best regards

Peter

Hi.

Actually, I have not resolved this problem. I am trying download code to mcu without mass erasing.

Hi Mesut,

I am sorry to hear that.

The write without mass erase for FRAM devices works, as the FRAM technology does not require an erase before writing, even if the memory cell should be changed from 0 to 1.

Still it should be possible to fix your issues with the mass erase. Unfortunately with our tools we are not able to reproduce your problem. That's why I recommended before, to start with our tools, at least for the debugging, to identify the differences between the failing scenario and a functional setup on your side.

Best regards

Peter