MSP430FR50431: MCU hangs after I send it a BSL password.

Hi David,

We are looking into the issue and will get you a detailed reply tomorrow - thank you for your patience. 

I noticed the Watchdog is enabled in the software - could you try disabling it by uncommenting that line and try again?

I don't know if this will help you, but it is possible the feature is disabled. Table 1 notes this:

(7) Some devices can disable mass erase on incorrect password. See the device family user's guide.

The user's guide says :

Two BSL signatures, BSL Signature 1 (memory location 0FF84h) and BSL Signature 2 (memory location
0FF86h) reside in FRAM and can be used to control the behavior of the BSL. Writing 05555h to BSL
Signature 1 or BSL Signature 2 disables the BSL function and any access to the BSL memory space
causes a vacant memory access as described in Section 1.9. Most BSL commands require the BSL to be
unlocked by a user-defined password. An incorrect password erases the device memory as a security
feature. Writing 0AAAAh to both BSL Signature 1 and BSL Signature 2 disables this security feature. This
causes a password error to be returned by the BSL, but the device memory is not erased. In this case,
unlimited password attempts are possible.

Just a couple of things to check. I do not know if there is a project setting for this.

Hi Ivan,

This may be of interest. I'll need to check and see if anyone on the team has experienced these settings before and has gotten similar behavior to what you are experiencing now with the BSL. 

I'll get back to you on Monday about this, thank you for your patience. 

Hello! So far I have tried stopping the watchdog timer as you suggested. The behavior is unchanged. I am now trying to change the clock configuration to see if it helps! I will also try to get the Uniflash to work to be 100% sure this is not a master-side error. Looking forward to hearing from you soon! - David

EDIT: I have tried making a simple LED-blinking program to see how fast the clock is (I am using default settings, not adjusting the clock speed) and it seems like it is running at 1MHz. This should not be a problem, since according to the BSL document, it should run on speeds less than or equal to 1Mhz. I have then changed the speed to 8Mhz, but the results are still the same. 

I will now try the Uniflasher tool.

EDIT2: Neither the Uniflasher nor the BSLScripter tools even bother to attempt to communicate with the device over I2C, according to my logic analyzer... I am using a MSP-Fet .
This is unrelated to my original problem, but it means I can only be 90% sure that it's not a master problem, as opposed to 100% sure.

EDIT3: I have checked the memory on addresses 0x0FF84 and 0x0FF86, as setting special values to the disables the erase-on-wrong-password functionality, as Ivan_B suggested.

  uint16_t* tempPtr;
    tempPtr=(uint16_t*) 0x0FF86;
    temp=*tempPtr;

According to the debugger, the values are 0xFFFF, though.


EDIT4: I have attempted to use the "erase memory" command instead of sending the first blank password. 

There was no change in the communication pattern (obviously, other than the one command I changed) . That is, instead of the communication to look like this:

>>BSL Version?
<<Not unlocked!
>>Empty password!
>>BSL Version?
<<Not unlocked!
>>Empty password!
>>BSL Version?
<<(DIES)

It looked like this:

>>BSL Version?
<<Not unlocked!
>>Erase memory!
>>BSL Version?
<<Not unlocked!
>>Empty password!
>>BSL Version?
<<(DIES)

This leads me to believe that the issue is related to the act of unlocking the memory. I went through the linker options, but couldn't find anything. I even invoked the linker from cmd, so it spits out all the possible flags and then I read through them, but I am not sure what I am missing... 

David,

It seems like you have tried everything in the "normal" procedures. I have not dealt with the FR series personally, but I have been looking into them, thus my interest in the topic. I think you are getting valid communications because you are getting back a "Not Unlocked" response. Assuming that is the MSP response to your queries, then I2C is not the issue. However, just to make sure, here are some notes I found in the Bootloader documentation. One thing I am not sure of based on discussions is how you are sending the BSL commands to the MSP430. Will you please explain this connection?

From the SLAU550Z – MSP430™ FRAM Devices Bootloader (BSL)

3.1.2 I2C BSL
I2C protocol used by BSL is defined as:
• The MSP430 BSL is the slave, and the master must request data from the BSL slave.
• 7-bit addressing mode is used, and the slave address is 0x48.
• Handshake is performed by an acknowledge character in addition to the hardware ACK.
• The minimum time delay before sending new character after characters have been received from MSP430 BSL is 1.2 ms.
• Repeated starts are not required by the BSL but can be used.

3.2.1 BSL Memory Layout
BSL application is factory programmed in the read-only memory area of the MSP430 devices and cannot be customized. The size of the BSL application differs among the device families:
• FR5xx and FR6xx BSL size is 2KB at address 0x1000 to 0x17FF. (so your address is correct)

3.2.2 BSL Z-Area
When protected, the BSL memory cannot be read or jumped into from a location external to BSL memory. This makes the BSL more secure and prevents erroneous BSL execution. However, if the entire BSL memory space were protected in this way, it would also mean that user application code could not call the BSL in any way, such as an intentional BSL startup or using certain public BSL functions. The Z-Area is a special section of memory designed to allow for a protected BSL to be publically accessible in a controlled way. The Z-Area is a section of BSL memory between addresses 0x1000 and 0x100F that can be jumped to and read by external application code. It functions as a gateway from which a jump can be performed to any location within the BSL memory. The default TI BSL uses this area for jumps to the start of the BSL and for jumps into BSL public functions.

3.2.3 BSL Memory Consideration
The BSL partially clear RAM contents at the beginning of BSL initialization to prevent reading out any application data or code that can reside there. After initialization, the BSL uses RAM for data buffer and local variables. When invoking the BSL from a main application, any RAM contents can be lost. The range of RAM that is cleared is listed in the tables in Section 7.

3.3 BSL Invocation
The following methods can be used to invoke the BSL application on the MSP430 FRAM devices:
• The BSL can be called by application software (see Section 3.3.1)
• The BSL can be called by the device boot code by applying a hardware entry sequence on the TEST and RST pins on the device (see Section 3.3.2)
• The BSL can be invoked at start up if the device is blank (see Section 3.3.3). This is applicable only for FR26xx, FR25xx, FR24xx, and FR23xx devices

3.3.1 Software BSL Invocation
The BSL Z-Area is a small section of memory that can be read and invoked from application code. It is located at memory addresses 0x1000 to 0x100F.

3.3.1.1 Starting the BSL From an External Software Application
Memory location 0x1000 contains a jump instruction pointing to the BSL start and can be used to invoke the BSL from a running application by setting the program counter to 0x1000. The stack is always reset, and RAM is cleared. Interrupts are not disabled by the BSL and should be disabled by the application before invoking the BSL. 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. One example is that in the FR23xx and FR26xx MCUs, the Timer_B module
executes the time-out calculation of the BSL. If Timer_B is also used in the external application and is not cleared before jumping to the BSL application, it could cause unexpected behavior. The location 0x1000 can be called as a C function, as in the following example code:

__disable_interrupt(); // disable interrupts
((void (*)())0x1000)(); // jump to BSL

NOTE: The BSL on FR5xx and FR6xx devices must be executed with a maximum frequency of 8 MHz. If the device operates at frequencies higher than 8 MHz, the MCLK frequency must be set to 8 MHz or lower before calling the BSL.

So far, I see everything that you are doing, from the clock speed to the code example... This is what I find interesting:

3.3.1.2 BSL Action
Memory location 0x1002 contains a jump to the "BSL Action" function. To invoke the action function, three parameters are needed. The first parameter is a number describing which function, and the other two parameters are known values that indicate that the function was called intentionally.
R12: The function number
R13: 0xDEAD
R14: 0xBEEF
The BSL on FR5xx 

and FR6xx devices always executes BSL Action function 2, regardless of the function number argument.

3.3.1.2.1 BSL Action Function 2
Function number: 2
Function Name: Return to BSL
Description: Any supplied function number calls the return to BSL function. This function can be used if the BSL has written a program into FRAM or RAM, started that program by "Set PC", and then the program needs to return to the BSL. This function executes the following code:
RETURN_TO_BSL
POP.W RET_low ; remove first word from return addr
POP.W RET_high ; remove second word from return addr
RETA ; should now return to the BSL location

So, When you call the BSL at 0x1000, it pop's the last 32 bit value from the stack and then runs RETA, which then jumps to the next stack value. I do not know what this will do if you don't have a value on the stack already.

Do you have access through JTAG? you should be able to see some of this through the JTAG. If so, try tunning the C code to the jump command, then step into assembly and see where it goes from 0x1002. This would show you if it is even getting into the BSL. Maybe it is jumping into a random memory space? This goes back to whether the commands you get are actually from the BSL or not. Can you probe some logic lines and provide the bytes that are being sent and received? That would help a lot.

I am sure this is a bunch of repeated information for you, I am just attempting to step through it in my mind as I am going through it myself. I am hoping something will pop out and help you.

Ivan

Apologies, you already did...

"I am able to send the "Check BSL Version" command to the device and the response I get indicates that I have yet to provide the correct password - I get the 0x00 ACK byte, 0x80 header, 0x02 length, 0x3B 0x04 cmd and message and a checksum."

So this obviously means youa re connecting to the BSL and not into random memory. Ignore my previous post...

Here is the next steps. Based on 3.5 BSL Version Number and (0x00, 0x80, 0x02, 0x3B, 0c04), you are getting back:

TI BSL, Header Byte, version 2, BSL API interfaces with FRAM, Timer_A based UART.

This seems right up to the UART part. If you are getting a response, then it should be receiving the proper command. Maybe the I2C comms is working for the UART based comms. Try using a UART protocol instead of I2C.

Hello, thank you very much for your reply!
However, I do believe that your interpretation of the received data is flawed: 

0x00 0x80 0x02 0x3B 0x04 

The 0x02 byte corresponds to the reply size; the 0x3B means "received message" and the message code is 0x04, which means "BSL locked".

Please, see page 13 of MSP430 FRAM Devices Bootloader (BSL) User's Guide (Rev. Z) .

You are correct. Thank you for clarifying that part.

Now that my brain is rebooted from teh weekend (sorry), are you getting a 0x00 or 0xFF response from the mass erase?

No worries! Usually 0xFF, but sometimes 0x00.

Hae you tried going into the project settings and disabling the MPU?

Hello, thank you for your reply. I have disabled the MPU in the project settings, as I said in my original post.

Yup... you did haha. Sorry. I can't think of anything else to try myself, so here's hoping that TI can find a solution for ya...

No worries!! Thank you very much for your time! They said they'd get to me yesterday, but they didn't, I think I will just respectfully ping 'em again, because I am kinda stuck and need this to be solved. 

EDIT: Aaron Barrera do you have any update for me, please?

Hi David,

I have a few questions in regards to your application to ensure that all of the steps are being followed correctly:

BSL Related

- What is the time delay between BSL commands? The minimum time delay before sending new characters should be at least 1.2ms.

- Could you provide a scope plot of the SDA/SCK signals or a logic analyzer to confirm that the timings are being met?

- Can you ensure that MCLK is less than 8 MHz before entering BSL?

- What is doing the BSL programming exactly if you are not using the BSL scripter or Uniflash?

- Are the supply voltages the same for the BSL host and MSP430 BSL device? 

I2C Related

- What value resistors are you using for your I2C lines? 

Hello!

I have experimented with various delays ranging from 10ms to 100ms.
I can provide you the scope stuff tomorrow!
I do believe that I have entered the BSL with MCLK equal to 1 Mhz - I have blinked an LED as a test before entering BSL and 8,000,000 cycles lasted 8 seconds. 

I am using a board based around the ESP32 chip from Espressiff.
I am using a software I2C library.

I have an application that uses the same I2C interface of the MSP chip to communicate with the ESP32 and it works fine, using the same I2C settings and the same hardware.

The supply voltages are 3.3V in both cases. 
The BSL responds to the communication, sending I2C ack bits and everything is going well until I actually attempt to unlock the bootloader. Then the MSP hangs, pulling sda LOW.

The resistors used are 10K, as opposed to the recommended 4.7K for I2C, but we had no trouble with those in the past.

The I2C clock is 100kHz.

First I ask for the current BSL version, BSL replies that it has not yet been unlocked.
Then I tell it to erase memory, not asking for any reply.



Then I ask about the version again.



Then I send it the blank password.

The next time I try to ask about the current version, it fails.

On the last trace, that is the ESP32 sending the header? And then it stipes because the MSP has pulled the line low, and it lost arbitration?

There was something I found a while back with the MSP430F2619 that using the I2C in Master mode, the STOP and IFG flags did not get cleared properly whenever it had a NACK response. I had to add a line that cleared all of the flags in order for it to recover. I do not know if this is a similar situation. Can you tell based on current draw if the MSP is still running, or is it going to sleep? Would it be possible to supply a current trace?

I assume you do not have control over the I2C flags in the MSP due to the BSL being run. If you can, try running the debugger and checking the I2C registers. See if these flags are getting stuck.

Hi David,

Your screenshots of your I2C timings when invoking the BSL seem adequate in your application as well as your hardware. 

We are engaging with another customer who may be experiencing a similar issue with the MSP430FR59941, and I have looped another member of my team for help. I am in the process of obtaining an MSP-FET to determine a potential root cause in the BSL interface since there do not seem to be any issues from the MSP430 perspective. 

I will keep you in the loop next week as my teammate and I take a deeper dive into the BSL interface and have more suggestions/potential solutions about why the MSP is getting hung up during invokation. 

Hello, thank you very much.

I have attempted to use MSP-FET to communicate with the MSP430 device before, but the MSP-FET did not even try to do anything with its SDA/SCL pins. For this reason, I have purchased the BSL - Rocket and I will try using that instead. 

I will do some experiments with Rocket over the weekend. 

Thank you very much for your support! -David

Hello. I have tried using BSL rocket to communicate with the processor, instead. 

It turns out that the BSL Rocket had an old firmware installed and didn't work at all as a result. 
We have successfully managed to flash the newest Firmware into BSL Rocket, so today, I will try to see if I can use the Rocket to communicate with the BSL. 

Do you have any updates for me? - David

Edit:

Even with the newest firmware, the MSP-BSL (Rocket) completely fails. It sends Start/AW:48/W and receives ACK, but then hangs, not sending additional clock signals. 

When I disconnect the MSP, it receives NACK and hangs the same way.

Edit 2:

I have managed to successfully flash the MSP using the MSP-BSL Rocket. (But not with my hardware, yet).

So far, it appears that the problem is in the master-side i2c implementation and might potentially be related to clock stretching.


I would like to address some of the issues that made it rather difficult for me to debug the problem so others reading this thread are aware of them and so they can be fixed by TI in the near future.

- The MSP-Fet I2C BSL support seems nonexistant or limited, I couldn't get the BSL-Scripter to force the MSP-FET to toggle the I2C lines at all!
- The Rocket programmer arrived with an ancient version of firmware; judging by the behavior, the version number was something below 2.1, but I cannot confirm this.
- The part of the MSP-BSL User's guide document, describing the procedure to update the firmware in BSL Rocket is outdated and non-applicable.
- the zip file, containing the newest BSL Rocket firmware, has deprecated versions of the TI-txt files and it was instead necessary to compile the firmware from the source code.

David,

Have you looked into the I2C registers that I mentioned a while back? I think it is worth a look at least. You will have to be connected via JTAG to get the debug information from it though.

Ivan

Hello, thank you, I haven't yet, but it seems like I managed to solve it already... I will try to confirm it shortly!!

Okay, I have sniffed the MSP-BSL to BSL communication and used that as a base to make changes to my communication procedure.
It appears that when sending a password, you always need to try to read the reply.

If the password is wrong, no reply is sent, you get NACK on your I2C bus after having sent the address of the MSP and you need to send the STOP signal.

If the device is correct, you get a generic reply, that you need to read!!
Failure to read this reply results in the behavior I have described.

As long as you read it, it seems like you're fine.

Since there sometimes IS no reply, I have skipped reading it altogether, which causes the described behavior.

I will see if there are no additional problems and if not, I will close the topic! 

Thank you very much for your help!

Great information! Thanks for letting us know the solution, David.

Hi David,

Thank you for providing us your sharing your solution and leaving pointers for Texas Instruments to address to improve debugging similar issues in the future. We are currently in the process of building BSL knowledge and updating our content/pages and will share your pointers with the team as we make updates. 

Let us know if there are any additional problems. Thank you as well Ivan for your support too.