MSP430FR59941: BSL error code 104 108

Hello,

You have to invoke the BSL before you can start talking to the device via I2C. This is typically done via a specific pattern on TEST and RST pins ro via SW invoke in your application. Assuming you are using an MSP-FET, you will have to make the proper connections, not only to I2C lines, but to the TEST and RST lines  of the MSP430 as well. 

Please see section 3.3 of the MSP430 FRAM BSL User Guide for BSL invoke methods. Keep in mind MSP-FET connection for BSL invoke (to TEST/RST) are different than typical 2-wire JTAG connections.

The chip is told to enter BSL prior to code download attempt.

Inside the MSP, I am lauching the BSL by setting the Program Counter to 0x1000.  (The BSL_START address for this chip.)  Interrupts are disabled. 

The MSP-FET is not being  used in any part of this programming attempt.  The msp430-i2cbsl-tool is being used to download the txt file to the MSP.

Hello,

The documentation we have on the embedded linux I2C tool is located in https://www.ti.com/lit/swra500 . Unfortunately, it isn't as in depth to show possible error codes. That maybe embedded in the linux package though.  

First let's check your HW connections. Make sure you are interfacing to the correct I2C pins, (P1.6 and P1.7 - -USCIB0). If that is solid, then look at some of the other HW / connection possible issues in the following app note: (www.ti.com/lit/slaa734 ). You can then make sure your I2C connection is solid by loading up the default I2C example to just talk to the host: https://dev.ti.com/tirex/explore/node?node=AJ1xfM1celCMlxpY9n3bNw__IOGqZri__LATEST (Slight porting needed to work on USCIB0 ). 

If your hardware is good, and you can talk to the device via example code with your setup, and you are still having issues, then next step would be to check BSL invocation. After that, take the Linux I2C BSL host out of the picture and utilize BSLScriptor with MSP-FET. 

When I launch the BSL with the HW approach, I can successfully program the chip.  This works either with or without the -n parameter.  (So the -n and whatever it may do, is "don't care".)

When I lauch the BSL with:

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

I see no sign that the chip actually does anything.

In the slau550aa.pdf there is:

3.3.2.1 Factors That Prevent Hardware BSL Invocation

Where can I find the equivalent software section?  i.e. Factors That Prevent Software BSL Invocation

Thank you

For future reference,... from SWRA500.pdf,... the -n parameter is explained:

For hardware
invocation, the timing pulse must be applied on the TEST and RESET pins before calling the terminal
application. If the hardware invocation is used, specify the –n option to omit the software invocation. If the
–n flag is not specified before any BSL command is issued, the terminal program sends an I2C write
transaction of the bytes specified in the invokeString array of the main.c file. By default, this invoke string
is represented by a character sequence of {0xCA, 0xFE, 0xDE, 0xAD, 0xBE, 0xEF, 0xBA, 0xBE}

{0xCA, 0xFE, 0xDE, 0xAD, 0xBE, 0xEF, 0xBA, 0xBE}

What is this invoke-string supposed to do?

{0xCA, 0xFE, 0xDE, 0xAD, 0xBE, 0xEF, 0xBA, 0xBE}

What is this invoke-string supposed to do?

Hello,

From a SW invoke perspective, there is nothing that prevents it from invoking in this method, as you are pointing the CPU to the BSL section of memory. The only exception is if BSL is disabled and the chip just resets.

Now the trick with SW invocation, is that before you invoke the BSL, you must configure the device back to default settings that the BSL expects. Otherwise, the BSL may not function properly. The two main culprits are clock speed and USCI settings. 

Please keep in mind, that the Linux I2C BSL program is meant to be utilized in an embedded system. As such it assumes there is application code on the MSP430 running with I2C that can accept an "invoke sequence" that the MSP430 then interprets and does what it needs to do in order to SW invoke the BSL. Since you are manually invoking the SW BSL invoke method, then form the Linux I2C BSL driver perspective, its the same as a HW invoke as this program doesn't have to issue a command to the MSP430 to go to BSL. 

For future reference,..... From msp430_i2c_bsl_linux_tools_v1_00_00_00.zip\msp430_i2c_bsl_linux_tools_v1_00_00_00\src\i2cbsl.h

/* Defines for response codes */
#define MSP430_STATUS_OPERATION_OK               0x00
#define MSP430_STATUS_PASSWORD_ERROR             0x05
#define MSP430_STATUS_TXTFILE_ERROR             0x101
#define MSP430_STATUS_RESET_ERROR               0x102
#define MSP430_STATUS_I2C_NOT_FOUND             0x103
#define MSP430_STATUS_I2C_TRANSACTION_ERROR     0x104
#define MSP430_STATUS_INVALID_RESP_HEADER       0x105
#define MSP430_STATUS_INVALID_RESP_LENGTH       0x106
#define MSP430_STATUS_INVALID_RESP_CRC          0x107
#define MSP430_STATUS_INVOKE_FAIL               0x108
#define MSP430_STATUS_VERIFICATION_FAIL         0x109

I've been trying to figure out what the USCI seettings should be for the BSL to run.  The best I have found is: from: swra500.pdf there is: 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.

Where can I find the modules or registers that are used by the BSL application?  (Do I have to look at the code?  Where is that code?)

Thank you

Hello,

The FRAM BSL User Guide, has a Section 7 Bootloader Versions, that lists devices, BSL versions, and BSL resources used. This will tell you what you need to reset. By reset, you reset the resource/peripheral to default settings of device startup as indicated by the register descriptions in the device User Guide. This is because BSL code assumes HW invoke which includes a device reset. 

When I take a look at memory 0x1000 with my JTAG debugger,... I see 0x3FFF which translates to JMP 0x1000.

I'm wondering if what I'm seeing is true?  i.e. If it is looping at 0x1000, well it is never going to into BSL.

Should I be able to see the contents of 0x1000 with a debugger?  Is the BSL (ROM) viewable with a debugger?

Thank you

 My code,... that is not launching the SBL:

  UCB0CTLW0 |= UCSWRST;              // halt the module's i2c
    UCB0CTLW0 &= ~UCSWRST;             // unhalt the module's i2c
    __disable_interrupt();
    ((void (*)(void)) BSL_START)();  // jump to bsl

Hello,

In IDE memory viewer, you cannot view ROM code, and thus will see 0x3FFF. 

By resetting of the peripheral before SW invoke, it is meant to reset all register settings associated with the peripheral. Namely, any control or clock registers. 

Also double check the BSL Signature memory area to make sure the BSL is not disabled. See Table 9 below taken from MSP430 Code Protection Features app note. 

The BSL signature is 0xFFFFFFFF

I am sure the BSL has not been disabled as the a HW_invoke does work.

I have never used a password to access the BSL.  With the HW_invoke, the first download attempt fails, the 2nd succeeds in "unlocking" the part.  I see this as: The failed attempt fails, the part gets erased, the default password now works for the 2nd attempt.  (Do I have this wrong?)

I must be missing a concept.  If I can read the part, I can read the password.  So what is the point in having a password?

Good to know HW invoke works. So your issue is most likely not setting the device in proper configuration before invoking BSL via SW. 

From BSL security standpoint on this device, it can be 1)Disabled 2)Password protected with Mass Erase 3)Password protected, no erase.

By default BSL is set to Password Protected with Mass Erase. This is why you have to try it twice as it give s a "wrong password" that mass erases the device, so you can provide a default password to unlock all BSL functionality. This way you can protect code on device, but still allow access say if you locked JTAG as well.