• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 79 subscribers
  • Views 1104 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP430F5419 Bootloader question

Paul Schoenke
Expert 1375 points
Other Parts Discussed in Thread: MSP430F5419

Hello:

I am using the MSP430F5419 MCU on a design for a supervisory and communication function.  The main system is running on an i.MX6 application processor on a single-board computer using Linux.

If talking with the MSP430 running our custom application code, and then we try to run the BSL update program, it would fail.  If we reboot the entire system and then enter and communicate with the bootloader before ever talking UART to our application code, then it works fine.  We can then run application code and the bootloader file load will be successful.


In an attempt to determine whether or not this was a Linux interface issue, we even integrated the entire bootloader program into our application software on the HMI side, and even then we had the exact same problem.

Can you offer some insight into why this would be and how we can better understand this problem so we can work around it or resolve it?

Any feedback or input is welcomed and appreciated!

Thanks again!

Paul

  • 0
    TI__Mastermind 49692 points

    Hi Paul,

    According to Section 6.5 Bootstrap Loader (BSL) in the datasheet, usage of the BSL on this device requires 4 pins (see Table 6-3), and the BSL entry requires a specific entry sequence on the ~RST/NMI/SBWTDIO and TEST/SBWTCK pins. If the interface between the application processor and the MSP430 only includes two UART RX/TX pins (and not the additional ~RST/TEST pins), there's no way for the BSL entry sequence to start properly without powering cycling the entire system.

    Take a look at Section 1.3 Standard RESET and BSL Entry Sequence in the MSP430 Programming With the Bootloader (BSL) app note for the appropriate entry sequence for this device.

    Let me know if this doesn't make sense.

    Regards,

    James

    MSP Customer Applications

  • 0 in reply to James Evans
    Expert 1375 points

    Thanks James!

    We are very familiar with that application note as we reviewed it in great detail.  We also believe that we have followed the BSL entry procedure.  We have control over the RST and TST pins.  We don't believe that is our issue.  Our issue is that, for whatever reason, we seem to be unable to communicate with the BSL over UART if we have previously been talking over the UART to application code running on the MSP430.  If we handle the BSL first, then later talk to the application, things are fine.  We only brought it up because we were previously having no issue talking to the BSL at any point.  We did change the board that talks to the MSP430, but the circuitry is equivalent/identical. I could provide schematics if you would like.

    Paul

  • 0 in reply to Paul Schoenke
    TI__Mastermind 49692 points

    Hi Paul,

    This is strange, especially since the circuitry hasn't changed. Perhaps, this is a timing issue on the entry sequence or a parity issue? Since this is a different board, it could be running faster than the previous board. Make sure the baud rate is at 9600 (or very close to this), as discussed in the NOTE on page 6 here. Also, keep in mind that the minimum time delay before sending new characters after characters have been received from the MSP430 BSL is 1.2 ms.

    Regarding the parity bit, it doesn't look like the BSL on the MSP430F5419 expects a parity bit (discussed on page 42 here), so if you're using even parity for your general UART communication, this could be a problem.

    Regards,

    James

    MSP Customer Applications

  • 0 in reply to James Evans
    TI__Mastermind 49692 points
    Hi Paul,

    Were you able to figure out this issue?

    Regards,

    James

    MSP Customer Applications
  • 0 in reply to James Evans
    Guru 58965 points
    James,

    The BSL code might assume that the system and peripheral register have the same setting after a BOR (which includes a fresh power up of the chip). This can be called a bug; when an application program changes the register settings and the system somehow started to run the BSL code without going through BOR, the BSL code runs into problems.

    For this reason, many users have found problems when they "jmp to BSL" from application (in many different MSP430 chips with Flash based BSL code). I even found the same kind of bug in a ROM based BSL code in some of the FR chips. (Katie Pier is aware of all these.)

    The situation for MSP430F5419 (without the A) is much worse. (That chip is not recommended for new design.) But if you can force a BOR before you start BSL, it might work.

    --OCY
  • 0 in reply to old_cow_yellow
    TI__Mastermind 49692 points
    Hi OCY,

    Thank you for your insightful reply. I'm sure it will be helpful for other users, especially those using the non-A devices.

    Regards,

    James

    MSP Customer Applications

**Attention** This is a public forum