• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Subscribers 81 subscribers
  • Views 3044 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Trouble with putting MSP-EXP430fr6989 into BSL mode via hardware entry sequence

Taylor Hardin
Intellectual 290 points
Other Parts Discussed in Thread: MSP-EXP430FR6989, MSP430FR6989, MSP430FR5739, ENERGIA, MSP430FR6972, MSP430FR69721

Just as the title says, I am trying to put an msp-exp430fr6989 (target board) into its Bootstrap Loader mode by sending the BSL init sequence to it's SBWTDIO (Reset) and SBWTCK (Test) from another board (master board). Specifically, I am pulling reset low, test high, two edges on test, reset high, and finally test low to complete the BSL hardware init sequence.

#define BSL_INIT_SEQUENCE()       \

st(                           \

BSL_RST_PIN_SET_LOW();    \
__delay_cycles (50);      \
BSL_TEST_PIN_SET_HIGH();  \
__delay_cycles (50);      \
BSL_TEST_PIN_SET_LOW();   \
__delay_cycles (50);      \
BSL_TEST_PIN_SET_HIGH();  \
__delay_cycles (50);      \
BSL_RST_PIN_SET_HIGH();   \
__delay_cycles (50);      \
BSL_TEST_PIN_SET_LOW();   \
 __delay_cycles (50);     \

)

After sending the BSL init sequence (which doesn't seem to actually put it into BSL), I send the target board a new basic blink program to run via UART from the master board. However, upon completing the program transfer and releasing the target board from BSL, it starts back up with it's old blink program instead of the new one. I'm inclined to think that I am using the wrong reset/test pins or sending the wrong BSL startup sequence, but I'm not entirely sure at this point. Any help would be appreciated.

  • 0
    TI__Mastermind 40320 points

    Taylor,

    Can you step through your code to see if SYSBSLIND is being set?  A correct entry sequence causes SYSBSLIND to be set and an added sequence of commands initiates the desired function.

    It seems you are sending the correct entry sequence for the FR6989. Can you share what speed you are running it at? There is a recommended minimum time for pin states at 250ns. This is detailed on page 6 of

    Can you also ensure the following:

    • That test is low before executing the entry sequence.
    • JTAG has no control over the MSP430 resources
    • That the supply voltage, Vcc, doesn't drop below its threshold and a power on reset (POR) is not executed.
    • That the RST/NMI pin is configured as a RST pin. If the NMI bit is set, it will not enter BSL.

    Thanks,

    Evan

  • 0 in reply to Evan W
    Intellectual 290 points

    I threw the set-up on the scope real quick and it looks like RST goes low for ~50 microseconds before TEST goes high for ~15 microseconds, low for ~15 microseconds, high for ~30 microseconds, and finishes goes and stays low. ~15 microseconds into TEST's last high, RST goes high. Am I correct in thinking that SBWTDIO is RST and SBWTCK is TEST? Should send the init sequence quicker? I had my target board poll its SYSCTL register checking to see if SYSBSLIND ever gets set, and it looks like it does, but I don't think it loads in the BSL program? How can I verify that JTAG has no controller over it's resources?

  • 0 in reply to Taylor Hardin
    TI__Mastermind 40320 points
    Taylor,

    Thanks for the quick reply. You are correct in assuming that SBWTDIO is RST and SBWTCK is TEST. It's good to hear that SYSBSLIND is getting set. This means that the entry sequence is doing its job. Can you please verify the pins that you are using for UART are P2.0 (BSLTX) and P2.1 (BSLRX)?

    If SYSBSLIND is being set, you don't have to worry about JTAG being in the way of the BSL (as you know, they share pins). Are you writing your own BSL program or are you using the BSL Rocket linked below?
    http://www.ti.com/tool/MSPBSL
  • 0 in reply to Evan W
    Intellectual 290 points
    I have the UART lines on 2.0 and 2.1 on my reprogrammer board (5739) going to the RXD TXD pins right by the dashed emulation line of the 6989. This code was written by somebody else in my lab, and allows an msp430fr5739 to reprogram another msp430fr5739. Currently, I am trying to configure the code so that we can reprogram an msp430fr6989, but I have been having trouble putting it into BSL mode.
  • 0 in reply to Taylor Hardin
    Guru 58965 points
    From what you said, it seems that the BSL entry sequence worked but the UART communication after that failed to get anything done.

    If you have an oscilloscope, you should be able to actually see how the two sides talk to each other. The signals on 2.0 and 2.1 are active low. The data-rate should be 9600 b/s. There should be a start-bit (low) followed by 8 data-bits, an even-parity bit, and a stop-bit which is not extinguishable from the idle state.

    What do you see? Was there a sync-byte from the master to the slave? Was there an ack-byte from the slave to the master?
  • 0 in reply to Taylor Hardin
    TI__Mastermind 40320 points
    Taylor,

    I too am interested in what you see on an oscilloscope. old_yellow_cow is correct, it does seem your BSL entry sequence worked. As he mentioned, please provide what you see on the lines between master and slave.
  • 0 in reply to old_cow_yellow
    Intellectual 290 points
    I will let you know (hopefully sometime tomorrow) what the scope shows. I just had a thought, unrelated to UART, and wanted to know what you think about it. The program I am using to reprogram the 6989 first takes in the new program to put onto the 6989 and parses its ELF file into commands to send over BSL. It appears that the 6989 is going into BSL mode, but not doing anything with the data sent over UART. I am wondering if there are differences between the 5739's rf2500 elf file and the 6989's tilib elf file? If there are, then my program might well be sending garbage commands to the BSL because it is currently trying to parse an elf file that it thinks was generated by rf2500. I am trying to go through my lab partners code for his elf parser, but its pretty large and sparsely commented so it might take a while. Just wanted to give a quick response and see if you thought my idea might be a legitimate concern.
  • 0 in reply to Taylor Hardin
    Guru 58965 points
    You may want to consider TI MSP.TXT format instead. It is extremely simple. Alternatively, INTEL Ext Hex format which include check-sum. These two formats are standard for many MSP programmers.
  • 0 in reply to Taylor Hardin
    TI__Mastermind 40320 points
    Taylor,

    Thanks, do please let me know what you see.

    I do have a few concerns with your statement though. When you are generating your ELF file, are you making sure to build the project for the device that you are trying to load? Using an output file built for FR5739 and trying to load that into an FR6989 sounds like it could be a problem.

    Also, have you thought of using a TI-txt file? It's a really easy format to parse, with just ASCII versions of the hex bytes with spaces in between and the address are specified for example "@4400" and the end of the file is a simple character "q". Please feel free to reference this link for more information on how to generate the TI-txt file. BSL Scripter, a standard BSL tool we have for our devices uses a TI-txt file for instance.

    processors.wiki.ti.com/.../Generating_and_Loading_MSP430_Binary_Files

    Please let me know what you find.
  • 0 in reply to Evan W
    Intellectual 290 points

    Yes I generate an elf file for the 6989. For example, I might write and compile a simple blink program "blink_6989.elf" and give it to the elf parser. So if there is a problem, it should be with the elf parser and not with the blink program itself. I will look into the TI-txt file, but I'll have to talk to the people who are heading the project to see if they want to switch over or not.

    EDIT: Is there a way to generate TI-txt files without use of CCS or Energia? We just use the ti-mspgcc tool-chain and terminal to code and program our boards.

  • 0 in reply to Taylor Hardin
    TI__Mastermind 40320 points
    Taylor,

    My apologies for the late reply. When I first got the notification that you posted, the EDIT did not appear so I was waiting on your response. I just checked now and saw you had edited your original post asking more questions.

    Regarding the MSP-GCC, you can use the GCC compiler inside of CCS now. Then CCS can make the TI-txt file. Is this an available option for you?
  • 0 in reply to Evan W
    TI__Mastermind 40320 points
    Taylor,

    Due to inactivity on this thread, I'm going to mark this thread closed. Please feel free to respond here to re-open the thread if you have any further inquires or questions regarding this issue.
  • 0 in reply to Evan W
    TI__Mastermind 49692 points
    I recently supported a very similar issue on MSP430FR6972. When the correct BSL entry sequence was provided to the device, it would not enter the UART BSL. The problem was caused by using the MSP430FR69721, which has an I2C BSL, instead of using the MSP430FR6972, which has a UART BSL.

    I wanted to follow-up on this thread to help anyone else who may be having the same issue.

    Regards,

    James

    MSP Customer Applications

**Attention** This is a public forum