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.

BSL entry point for MSP430i202 and MSP430i2040

Other Parts Discussed in Thread: MSP430G2553, MSP430I2040

I know the entry point for the BSL in the MSP430G2553 is 0x0C00. I can't find any references that give the entry point(s) for the MSP430i202 and MSP430i2040. What version(s) of the BSL are they and what entry points do they have? Thanks.

  • Hi Lee,

    The i2040/3x/2x doesn't have BSL.

    Regards,
    Luis R
  • Hi Luis,

    According to the product search table on TI's web site, they both have UART BSLs. Is this incorrect?

    Lee

  • Unfortunately yes, it seems to be incorrect.

    I'll submit a bug request to fix it

    Thanks,
    Luis R
  • Luis,

    How close to the built-in BSL protocol is the code in TI_MSPBoot_CI_NWK_APP_BSL_UART.c? I'm more concerned about having to write new code for our master side, which is already handling the G2552. If this code isn't close, is there any other BSL code available that handles the same protocol? Thanks.

    Lee
  • sorry, that should be G2553.
  • Unfortunately, the BSL-based protocol in MSPBoot is not the same as G2xx BSL.

    We have the BSL code available for F5xx (in SLAA450) but that one is also different from G2xx BSL. As far as I know, we don't have the source code for G2xx BSL available, but let me double-check.

    Regards,
    Luis R
  • Hi Luis,

    Do you have any update on source code for, or close to, the BSL code in the G2553? A number of decisions were based on the fact that we could update all of our devices in the field and this misunderstanding is causing some concern. Thanks.

    Regards,

    Lee

  • Hello Lee,

    Luis is out of office for the next week so I will be picking up his efforts on this question. Our software engineer has not yet replied regarding the availability of BSL code for G2xx devices but we hope to hear from him by the end of tomorrow.

    Regards,
    Ryan
  • Hello Lee,

    I've gotten word back from our software engineer that the BSL code for G2xx will be included in the next update of SLAA450.

    Regards,
    Ryan
  • Hi Ryan,

    Any idea on a time frame? I need to get started on something immediately. Any chance I could get the code now?

    Regards,

    Lee
  • Hi Lee,

    I've already replied asking for a time frame and the possibility of sending mentioned code directly, but seeing as he is operating in Europe I would not expect a response until tomorrow morning.

    Regards,
    Ryan
  • Hi Ryan,

    I've started taking a look at the code for MSPBoot. It looks pretty straightforward so far, except for one thing. I don't see where boot.c is included in the build process, either in the project or in any of the code files. Can you tell me how this gets built into the project?

    I started looking at MSPBoot for several reasons. I discovered on Friday that the BSL in the g2553 uses pins other than the UART for serial communications. this would present a problem since our hardware assumes we're communicating over the UART pins. And settling on MSPBoot would allow us to use the same firmware update process on processors without a built-in BSL.

    Regards,
    Lee
  • Hi Lee,

    I assume we are discussing the MSPBoot project under MSPBoot -> Target -> G2553_UART? Since boot.c is under the same file path as main.c the file is definitely automatically included in the build process. Are you getting errors in CCS that say otherwise? If so, please attach a screenshot of the error descriptions.

    As shown in Table 19 of SLAA600, the MSPBoot G2553 solution uses the UCA0 peripheral (P1.1 & P1.2) for UART mode and UCB0 peripheral (P1.6 & P1.7) for I2C mode. This is because UCA0 is the only USCI peripheral on the G2553 device that supports UART, I2C was most likely chosen for UCB0 so that it would be separated from the backchannel UART pins on the MSP-EXP430G2 devices.

    Regards,
    Ryan
  • Hi Ryan,

    Yes, that's the project I'm working with. I'm actually working with the IAR compiler. My question is not that I'm getting a build error (I'm not) but I don't see boot.c included anywhere as part of the build process. I'm looking to understand what's going on, rather than fix a specific problem. I've copied over the files that I needed to create a version of the bootloader for my application (primarily leaving out the AppMgr files) and successfully built what I beleive is a boot loader. I didn't see boot.c actually used anywhere. Is it used in the build and if so, where? I even tried renaming boot.c to something else, and rebuilt my project with no problem.

    MSPBoot does use the UART. I was referring to the built-in BSL in the MSP430G2553 that switched to other pins in BSL mode.

    Regards,
    Lee
  • Lee,

    The custom boot.c is used to override the _reset_vector and _stack of the boot.c file included in the runtime support library. Katie gives a great explanation in another thread:
    e2e.ti.com/.../1410598

    If you were to exclude the custom boot.c from the project it would still build due to the runtime support library boot.c but the _reset_vector and _stack would not be properly overwritten for MSPBoot application.

    Since the built-in BSL uses I2C I believe we are on the same page.

    Regards,
    Ryan

**Attention** This is a public forum