This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430FR2355: MSP430FR2355 , BSL , Does not erase or load new code.

Part Number: MSP430FR2355
Other Parts Discussed in Thread: MSP-EXP430FR2355, MSP-FET

Using the code below I load, run in debug mode in CCS-8. I run the scripter. I get numerous NACK returns and upon power cycle the MSP430FR2355 runs the code previously loaded, not the new code loaded thru the BSL scripter.

Code:

#include <msp430.h>


int main(void)
{
//**************************************************************************************
// Clock Configuration
//**************************************************************************************

// Stop Watch Dog Timer
WDTCTL = WDTPW | WDTHOLD;

// Configure one FRAM wait state as required by the device data sheet for MCLK
// operation beyond 8MHz _before_ configuring the clock system.
FRCTL0 = FRCTLPW | NWAITS_1;

__bis_SR_register(SCG0); // disable FLL

CSCTL1 = DCORSEL_3;// DCO Range = 8MHz

CSCTL2 = FLLD_0 + 243; // DCOCLKDIV = 8MHz

__delay_cycles(3);

__bic_SR_register(SCG0); // enable FLL

// Disable the GPIO power-on default high-impedance mode to activate
// previously configured port settings
PM5CTL0 &= ~LOCKLPM5;

__disable_interrupt();
((void (*)() )0x1000)();

}

  • If someone could just get me the source code for this:
    BSL version
    00.09.36.B4
    I could probably figure out what is going on.
  • Hi Don,

    Below is a link to some BSL resources. We don't have the exact version (00.09.36.B4) you are referencing, but they should be similar. The version in the BSL folder link is 00.08.35.B3. You will want to look at the API > BSL430_API_FRAM.c, Command_Interpreter > BSL430_Command_Interpreter.c, and Peripheral_Interfaces > eUSCI_UART_I2C > BSL430_PI_eUSCI_UART_I2C.c files.

    software-dl.ti.com/.../index_FDS.html

    I also had a few questions I was hoping you could answer.

    Is there a reason you are implementing a wait state? If you are running at 8MHz, you shouldn't have to do this. Could you try running your SW without a wait state?

    Also, how are you communicating to the PC during your debug session? Is it through the eZ-FET?

    Could you send screenshots of the NACKs you mention?

    Thanks,

    Mitch
  • Can you help me find the referenced files?  I open that link and it looks like the standard non-FR code.  I went through every link.

    I am not sure about the wait state.  There are two of us working on this issue and Wes might have taken some advice somewhere to include the wait state.  I have tried it with just this simple CC8 startup code without results. I think this would be running at the default clock speed, just as if it was invoked with hardware.  I will try to figure out the waitstate thing and try it both ways, also with an 8MHz clock.

    We have just the standard FET probe.  I've tried it with and without thinking that the TEST line or RESET was interfering. 

    I have to setup again, but I guess Wes mentioned the Nacks.  There are no Nacks, just the absence of any data coming back. 

  • Hi Don,

    Sorry for not clarifying. When you click on the link I posted above, click on the "MSP 430 Custom BSL Package" link toward the bottom of the page. This will be the most recent BSL folder. Once you are in the MSP430BSL_1_01_00_01 folder, the files can be found at:

    IAR_BSL_Source > API > BSL430_API_FRAM.c
    IAR_BSL_Source > Command_Interpreter > BSL430_Command_Interpreter.c
    IAR_BSL_Source > Peripheral_Interfaces > eUSCI_UART_I2C > BSL430_PI_eUSCI_UART_I2C.c

    These files will look similar between Flash and FRAM devices.

    I am very curious to see what happens if you get rid of the wait state. The clock needs to be less than or equal to 8MHz (which you are doing). Wait states shouldn't be necessary and I am wondering if it could be causing problems.

    Please let me know what you see with the wait state removed.

    Thanks!

    -Mitch
  • I'm attempting to build a linkable version of this - any ides where I can find this file for the MSP430FR2355?

    #include "BSL_Device_File.h"

  • Hi Don,

    I am checking to see if that file is available.

    Thanks,

    Mitch
  • Would it be possible to contact the group and get the correct code for this SKU and send to me?  I am happy to sign an NDA.  I really need to get this resolved somehow.  Is there a development board that someone can test?  This shouldn't be this hard.

  • Hi Don,

    We ran some tests with the code you provided and it looks like it's working. We saw that the device jumps to BSL and stays there to wait for a BSL command. We tested it with a SET_BAUDRATE command.

    Below is a picture of the SET_BAUDRATE command being sent with a response of 0x00 (which is what we expect to see)

    Here is a link to the FRAM BSL User's Guide where you can see example responses for several different BSL commands (including SET_BAUDRATE).

    It may take time for me to be able to send the file you are requesting (assuming I get the permission to do so). However, it looks like it's working on our end.

    Can you send me screenshots of the exact problem you are seeing?

    Thanks,

    Mitch

  • Hi Don,

    Were you able to resolve your issue? I will close out the thread if there are no additional questions.

    Thanks!

    -Mitch
  • Mitch, I am back working on this now. We discovered we were using the wrong UART and thought that would fix the problem. This weekend I was able to move the UART successfully to UCA0 from UCA1 and make an adapter cable to download using SBW vs. 4 wire JTAG. When I invoke the BSL, it executes a few calls in assembly code, then drops the TX line (P1.7) low and is looking for some condition that never comes true and just hangs.
  • Hey Don,

    Just to clarify, you are trying to invoke the BSL via SW still, right? With the following lines?

    __disable_interrupt();
    ((void (*)() )0x1000)()

    -Mitch
  • Yes.  Here is the ZIPPED project export.sent2ti.zip

  • I now have the LaunchPad board setup with a serial port on A0 and it successfully runs our code.  I then go to the top of main and set a breakpoint.  Once it breaks, I find this code and I "Move to Line"

                   __disable_interrupt();
                  FRCTL0 = FRCTLPW | NWAITS_1;
                  __bis_SR_register(SCG0);                           // disable FLL
                  CSCTL1 = DCORSEL_3;// DCO Range = 8MHz
                  CSCTL2 = FLLD_0 + 243;                             // DCOCLKDIV = 8MHz
                  __delay_cycles(3);
                  __bic_SR_register(SCG0);                           // enable FLL
                  // Disable the GPIO power-on default high-impedance mode to activate
                  // previously configured port settings
                  PM5CTL0 &= ~LOCKLPM5;
                  ((void (*)() )0x1000)();


    I execute into the BSL and after the point where the BSL code is setting up the clock registers, it executes a MOV.W into computed memory, and at that point the TX line looks like it is changed to an input.  It never gets set to be the TXD output (remains an input) and at some point the code hangs. 

  • Previously, Mitch had sent me this screenshot of a working 2355 responding to the Set Baudrate command.  I noticed that the TX line was actually low until it saw data coming in, so I replicated this sequence, however, there was no change the TX line is still floating.  (It does transmit in my application.)  The test was done on the LaunchPad.  For the LaunchPad, I have taken P1.6 and P1.7 and level shifted them to RS232 levels for my BSL_RX and BSL_TX. 

  • Hey Don,

    One thing I'd like you to check. Can you right click on the project in CCS and go to Properties > General > MPU and make sure that the “Enable Memory Protection Unit (MPU)” box is not checked? I think this may be checked by default. Please uncheck this (if it is checked), rebuild the project, and see how the BSL behaves.

    Thanks,

    Mitch

  • You mean this:

    Guess it is different for FR types.  It was checked, I unchecked it and tried both the scripter and the SET BAUD RATE commands with the same negative results.

  • Hey Don,

    Yes, thanks for pointing that out. I forgot this device doesn't have an MPU. Can you try disabling both boxes (Enable FRAM Write Protection & Protect data FRAM memory)?

    The DFWP and PFWP bits should be cleared to 0 in the SYSCFG0 register.

    Thanks,

    Mitch
  • I was not able to get them both to clear:

    Also, I looked in the register, and the bits were 1 after a clean rebuild with it set as above:

  • Hey Don,

    Can you try clearing those bits in SW before you try the BSL invocation?

    Thanks,

    Mitch
  • I can't seem to make those bits stick at 0. Got any ideas?
  • My abbreviated code that just jumps to the BSL doesn't execute a lot of code before it jumps to main, but my production app does. I was able to break in __mpu_init() where it sets that register and change R15 right before it wrote it back to SYSCFG0. That did clear the bits, but it still didn't make it work.
  • My abbreviated code that just jumps to the BSL doesn't execute a lot of code before it jumps to main, but my production app does. I was able to break in __mpu_init() where it sets that register and change R15 right before it wrote it back to SYSCFG0. That did clear the bits, but it still didn't make it work.
  • Hey Don,

    Did you provide the password to unlock the register? Something like this should work:

    SYSCFG0 = FRWPPW | DFWP | PFWP;

    Thanks,

    Mitch
  • Mitch - I made some progress!

    I set the customer configuration block such that it forced serial download (vs. auto config) and I got a response to my SET BAUD.  I suspect that the autoconfig is not working properly on the part, or that our I2C devices out there are causing it to think its an I2C transfer.  I will let you know if I can actually download software once I jump that hurdle. 

  • Great! Yes please keep me updated

    -Mitch
  • Turns out I only got to see it try to work that one time, then I lost the formula.  I added code to get the bslConfig to work.  This was from your SLAU550P document around page 11, with one exception:

    // ******************************************************************************
    // BSL Config
    // ******************************************************************************
    #define BSL_CONFIG_SIGNATURE (0x695A) // BSL Configuration Signature
    #define BSL_CONFIG_PASSWORD (0x5A00) // BSL User's Configuration Signature
    #define BSL_CONFIG_TINY_RAM_ERASED_BY_INIT (0xFFF7) // Tiny RAM is erased during BSL invocation
    #define BSL_CONFIG_TINY_RAM_NOT_ERASED_BY_INIT (0xFFFF) // (Default) Tiny RAM is not erased during BSL invocation
    #define BSL_CONFIG_RAM_ERASED_BY_INIT (0xFFFB) // RAM is erased during BSL invocation
    #define BSL_CONFIG_RAM_NOT_ERASED_BY_INIT (0xFFFF) // (Default) RAM is not erased during BSL invocation
    #define BSL_CONFIG_INTERFACE_UART_I2C (0xFFFC) // Enable UART and I2C
    #define BSL_CONFIG_INTERFACE_UART_ONLY (0xFFFD) // Enable UART
    #define BSL_CONFIG_INTERFACE_I2C_ONLY (0xFFFE) // Enable I2C

    #pragma RETAIN(bslConfigurationSignature)
    #pragma DATA_SECTION(bslConfigurationSignature, ".bslconfigsignature")
    const unsigned int bslConfigurationSignature = BSL_CONFIG_SIGNATURE;
    #pragma RETAIN(bslConfig)
    #pragma DATA_SECTION(bslConfig, ".bslconfig")
    const unsigned int bslConfig = (BSL_CONFIG_PASSWORD | ~BSL_CONFIG_INTERFACE_UART_ONLY);

    I had to add the ~ in front of BSL_CONFIG_INTERFACE_UART_ONLY.  don't know how this was intended to to work as written.  As you can see my configuration is now in memory:

    This is the code I was jumping to to invoke:

                  __disable_interrupt();
                  FRCTL0 = FRCTLPW | NWAITS_1;
                  __bis_SR_register(SCG0);                           // disable FLL
                  CSCTL1 = DCORSEL_3;// DCO Range = 8MHz
                  CSCTL2 = FLLD_0 + 243;                             // DCOCLKDIV = 8MHz
                  __delay_cycles(3);
                  __bic_SR_register(SCG0);                           // enable FLL
                  // Disable the GPIO power-on default high-impedance mode to activate
                  // previously configured port settings
                  PM5CTL0 &= ~LOCKLPM5;

                  ((void (*)() )0x1000)();

    My SYSCONFIG0 is at x09603.  I think this is the protected mode, but your code example had me setting the bits, so I'm not sure.  It doesn't seem to make a difference. 

    I don't know what I might have done differently when it worked, still trying to figure it out.

    Can you help further?

  • Mitch - I found the formula again! Turns out ~BSL_CONFIG_INTERFACE_UART_ONLY = 2 , not 1 like its supposed to. I'm not sure how all that was intended to work but when I changed it to 1 then I am back setting the baud rate again.
  • Hey Don,

    Are you able to run other BSL commands as well? Does it seem to be working?

    Thanks,

    Mitch
  • It is very unstable.  Sometimes I can set baud rates, sometimes I cannot.  I haven't been able to actually program anything yet.  Actively working it now.

  • Can you try redefining BSL_CONFIG_INTERFACE_UART_ONLY to 0x00FD? I wonder if the

    const uint16_t bslConfig = (BSL_CONFIG_PASSWORD | BSL_CONFIG_INTERFACE_UART_ONLY) ;

    operation is corrupting the BSL_CONFIG_PASSWORD when BSL_CONFIG_INTERFACE_UART_ONLY = 0xFFFD
  • That looks like an error in the manual to me, if not I certainly don't understand it. I think bslConfig should be 0x5A01, and that is what I am setting it to.
  • I also think the manual may have an error. I am going to double check with our team.

    So you are still getting faulty behavior when explicitly writing 0x5A01 to blsConfig?
  • I am. I'm trying to find a stable set of conditions.
  • I cannot find a stable set of conditions. Sometimes the BSL responds, but I cannot say for sure it has ever executed the command. I can get it into a mood to respond with a 0x51 error consistently - sometimes. It just seams like TI could say: Do this, and this and this and this and then it will work. Can you please escalate this to someone that has access to a FR2355 and can tell me what I need to do to get over this? This is now in the critical path for delivery of 18 imaging computers to the military. It is critical to us that this be resolved.

    Here is the code I'm working with:

    #include <msp430.h>

    #define BSL_CONFIG_SIGNATURE (0x695A) // BSL Configuration Signature
    #define BSL_CONFIG_PASSWORD (0x5A00) // BSL User's Configuration Signature
    #define BSL_CONFIG_TINY_RAM_ERASED_BY_INIT (0xFFF7) // Tiny RAM is erased during BSL invocation
    #define BSL_CONFIG_TINY_RAM_NOT_ERASED_BY_INIT (0xFFFF) // (Default) Tiny RAM is not erased during BSL invocation
    #define BSL_CONFIG_RAM_ERASED_BY_INIT (0xFFFB) // RAM is erased during BSL invocation
    #define BSL_CONFIG_RAM_NOT_ERASED_BY_INIT (0xFFFF) // (Default) RAM is not erased during BSL invocation
    #define BSL_CONFIG_INTERFACE_UART_I2C (0xFFFC) // Enable UART and I2C
    #define BSL_CONFIG_INTERFACE_UART_ONLY (0xFFFD) // Enable UART
    #define BSL_CONFIG_INTERFACE_I2C_ONLY (0xFFFE) // Enable I2C

    #pragma RETAIN(bslConfigurationSignature)
    #pragma DATA_SECTION(bslConfigurationSignature, ".bslconfigsignature")
    const unsigned int bslConfigurationSignature = BSL_CONFIG_SIGNATURE;
    #pragma RETAIN(bslConfig)
    #pragma DATA_SECTION(bslConfig, ".bslconfig")
    const unsigned int bslConfig = (BSL_CONFIG_PASSWORD | 1);

    /*
    * main.c
    */
    int main(void)
    {
    WDTCTL = WDTPW | WDTHOLD; // stop watchdog timer

    __disable_interrupt();

    FRCTL0 = FRCTLPW /*| NWAITS_1*/;
    // __bis_SR_register(SCG0); // disable FLL
    // CSCTL1 = DCORSEL_3;// DCO Range = 8MHz
    // CSCTL2 = FLLD_0 + 243; // DCOCLKDIV = 8MHz
    __delay_cycles(90000);
    // __bic_SR_register(SCG0); // enable FLL

    // SYSCFG0 = FRWPPW;
    ((void (*)() )0x1000)();

    }
  • Hey Don,

    I was able to get a hold of a FR2355 Launchpad and ran some tests. When I tried to do a BSL invocation with the code you provided above (with no alterations), it didn't work. However, when I commented out all of the user defined configuration settings (all of the #defines and #pragmas between #include <msp430.h> and main) it worked. I was able to run the CHANGE_BAUD_RATE, RX_PASSWORD, and TX_BSL_VERSION commands successfully. I did not make any other alterations to your code.

    Does your system require you to implement user defined settings to erase tiny RAM and RAM? If the default settings are acceptable, you don't need the user defined settings to invoke the BSL.

    Thanks,

    Mitch
  • So you are saying that usingthe MSP-EXP430FR2355 card, with P1.6 and P1.7 connected to an RS232 converter and the output of the converter connected to your PC and with the USB port connected to your PC, you run Code Composer and download and run the following code:
    #include <msp430.h>
    /*
    #define BSL_CONFIG_SIGNATURE (0x695A) // BSL Configuration Signature
    #define BSL_CONFIG_PASSWORD (0x5A00) // BSL User's Configuration Signature
    #define BSL_CONFIG_TINY_RAM_ERASED_BY_INIT (0xFFF7) // Tiny RAM is erased during BSL invocation
    #define BSL_CONFIG_TINY_RAM_NOT_ERASED_BY_INIT (0xFFFF) // (Default) Tiny RAM is not erased during BSL invocation
    #define BSL_CONFIG_RAM_ERASED_BY_INIT (0xFFFB) // RAM is erased during BSL invocation
    #define BSL_CONFIG_RAM_NOT_ERASED_BY_INIT (0xFFFF) // (Default) RAM is not erased during BSL invocation
    #define BSL_CONFIG_INTERFACE_UART_I2C (0xFFFC) // Enable UART and I2C
    #define BSL_CONFIG_INTERFACE_UART_ONLY (0xFFFD) // Enable UART
    #define BSL_CONFIG_INTERFACE_I2C_ONLY (0xFFFE) // Enable I2C

    #pragma RETAIN(bslConfigurationSignature)
    #pragma DATA_SECTION(bslConfigurationSignature, ".bslconfigsignature")
    const unsigned int bslConfigurationSignature = BSL_CONFIG_SIGNATURE;
    #pragma RETAIN(bslConfig)
    #pragma DATA_SECTION(bslConfig, ".bslconfig")
    const unsigned int bslConfig = (BSL_CONFIG_PASSWORD | 1);
    */

    int main(void)
    {
    WDTCTL = WDTPW | WDTHOLD; // stop watchdog timer

    __disable_interrupt();

    FRCTL0 = FRCTLPW /*| NWAITS_1*/;
    __delay_cycles(90000);
    ((void (*)() )0x1000)();
    }

    and then you run BSL-Scripter 3.4.0.1 with the following script:

    MODE FRxx UART 9600 COM16
    VERBOSE
    TX_BSL_VERSION

    You get a response?

    I don't get anything with that configuration.
  • Mitch, can you comment?

  • Hey Don,

    Your set up is slightly different than mine. I am using the MSP-FET tool to connect the FR2355 board to the PC. The pins (1.6 & 1.7) and the EVM board are the same.

    Yes, the SW you posted (with the user config settings commented out) is what I am programming to the board.

    Do you have a converter in your RS232 circuit to convert the RS232 voltages to 3.3V for the MCU? I believe the RS232 voltage range may be out of the spec for MSP devices.

    Could you try using the MSP-FET tool if you have one on hand?

    Thanks,

    Mitch
  • I would, but I do not know how to use a MSP-FET tool for that purpose. Any chance you can call me?
  • I think I figured out how you have it hooked up:

    Ran the above code, then ran BSL_Scripter with this:

    MODE FRxx UART 9600 COM9
    VERBOSE
    TX_BSL_VERSION

    (COM9 is my MSP Application UART 1)

    No returned data. 

  • Hey Don,

    When you remove the ribbon from the MSP-FET, you will want to use jumper wires to connect the MSP-FET to the EVM. Use pin 2 (VCC_TOOL) for power, pin 9 for GND, pin 12 for TX, pin 14 for RX. 

    I also noticed you are running the TX_BSL_VERSION command. This is a protected command, which means you will need to provide the RX_PASSWORD before the device will respond to this command. Instead of trying the TX_BSL_VERSION command, can you try the CHANGE_BAUD_RATE command? This is not protected. Some examples of the format for this command are:

  • It also looks like there is a timeout feature on the FR2355 device. When you are testing the BSL, you may need to press the reset button before you try to send a BSL command to guarantee that the device can receive BSL commands.

  • Good news.  I have that working reliably.  Finally.   I am going to get downloading working on the Launch Pad before I figure out why it isn't working on my hardware.

    Is this the proper script.txt?

    MODE FRxx UART COM20
    MASS_ERASE
    DELAY 200
    RX_PASSWORD pass32_default.txt
    RX_DATA_BLOCK NVL new UART.txt

    Is this the password:

    pass32_default.txt

    @FFE0
    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
    q

  • Awesome! We are making progress!

    Your script looks good except for your password. The BSL password is the data in the interrupt vector from 0xFFE0 to 0xFFFF:

    You can find this data by programming your device in CCS (but do not run it), then going to View > Memory Browser. You should see a window like this:

    This is the data I see when I programmed the device with the SW you provided (with the user configurations commented out). You will want to make sure your password file matches the data in this region. The password file I used with your code was this:

    @FFE0
    46 80 46 80 46 80 46 80 46 80 46 80 46 80 46 80
    46 80 46 80 46 80 46 80 46 80 46 80 46 80 32 80
    q

    You will need to keep in mind the endian-ness for the password file. Input the lower-byte first, then upper byte. You can see that my last 2 data bytes (from address 0xFFFE and 0XFFFF) are different since this is my reset vector data.

  • Also a quick note - you will want to make sure your NVL new UART.txt file for the RX_DATA_BLOCK command is in the same folder:

  • Sorry to interrupt the thread, but I've been following this, and am confused.  Just for my education, if you are using a Launchpad instead of an MSP-FET to connect to the FR2355, why don't you need "PARITY" on the BSL-Scripter MODE line?  I thought only the MSP-FET and the Rocket provided the even parity needed by the chip's BSL.  Does the launchpad provide that too?

    And I guess the same question applies with respect to the BSL hardware invocation pattern on /Reset and Test, which I thought the MSP-FET or Rocket provided, not BSL-Scripter.  How are you making that happen with a Launchpad and Scripter?

  • Hi George,

    We don't need "PARITY" on the BSL-Scripter MODE line because we are indeed using the MSP-FET tool. Sorry if this wasn't clear earlier in the thread.

    The setup we have is:

    PC connected to MSP-FET via USB > MSP-FET connected to FR2355 launchpad via jumper wires (jumper wire connections are VCC, GND, TX, and RX). This allows us to power the FR2355 launchpad with the MSP-FET tool. All BSL communication to the FR2355 launchpad is being done via MSP-FET.

    Thanks,

    Mitch

  • Thanks Mitch.  And is Don Harrison using an MSP-FET too?

  • I am.

    Where is this need for "PARITY" coming from?

  • Hey Don,

    BSL devices usually communicate with the even-parity format. However, we don't have to explicitly set the parity in the script because the MSP-FET tool takes care of this for us.

    Here is a link to the BSL Scripter's User Guide if you would like more info. The MODE command details are in section 2.4.1

    www.ti.com/.../slau655f.pdf

**Attention** This is a public forum