- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
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)();
}
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
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.
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:
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.
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?
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.
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:
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
**Attention** This is a public forum
