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.

MSP430FR2633: Software BSL Invocation with MSP-CAPT-FR2633 over I2C

Part Number: MSP430FR2633
Other Parts Discussed in Thread: MSP430F5529, MSP-FET,

Should we able to SW invoke I2C BSL with MSP-CAPT-FR2633?

HW invoke seems to work fine https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/599242

(though how are they connecting to the TST pin on the EVM?  Don't see it going to a jumper.  Only a connector.  Is it OK to tie TST low?)

And using the following SW invoke code, I can see connected with CCS that I am in the BSL

__disable_interrupt(); // disable interrupts ((void (*)())0x1000)(); // jump to BSL

But seem to be stuck in a &USCI_A0__UART_Mode_UCA0IFG test loop.

Do we need to do something special to get to I2C BSL?  Are we stucj in UART BSL?  Do we have to HW invoke to get I2C?

  • Hi Joe,
    It is important that if you can make sure it is the eUSCI having problem.

    Best regards,
    Cash Hao
  • Thanks, but already proved I2C tranfer with some generic code on the same setup (bus analyzer and CCS confirmed the values).

    I do have JTAG connected but also tried with run free and CCS connection terminated.

    Didn't want to do anything fancy. Just prove with BSL communication with a mass erase command (0x15).
  • Quick update, using MSPBoot host code on an MSP430F5529 Launchpad from:
    \MSPBoot_2_00_00_01\MSPBoot\Host_Examples\Host_Examples_for_F5529_Target\I2C\Host_F5529_Target_F5529_I2C_MSPBoot

    I can see the the 0x48 FR2633 BSL slave address and 0x80 header on an I2C bus analyzer (and scope)

    But then gets stuck at this line of code on i2c.c

        while (!(UCB0IFG & UCTXIFG));
        crcl = (uint8_t)(tPacket.ui16Checksum & 0xFF);
        UCB0TXBUF = crcl;

    I can even see the 0x15 mass erase command in UCB0TXBUF waiting to get sent out.  Most of the way through the I2C PI packet below from p. 19 of slau550p.pdf

    Do we need an ACK from the FR2633 BSL in the middle of the PI packet?

    Feels like the I2C BSL is not responding?  Again, how do I invoke I2C BSL on the MSP-CAPT-FR2633 in SW?

    Please see PI packet excerpt below:

  • Excerpt didn't attach above:

  • As a quick test I "faked" the BSL on the MSP-CAPT-FR2633 by adding some I2C slave receive code. 

    Attached is the I2C bus analyzer trace which shows the Host_F5529_Target_F5529_I2C_MSPBoot.out code matching the above I2C PI exactly (with some previous experimental transfers later).

    So it really feels like I am not invoking the I2C BSL correctly?  How do I do this with HW or SW invocation as requested above?

      

  • Hello Joe,

    Can you try to reset the peripherals before SW entering the BSL?

    The clock peripheral, eUSCI_A0 peripheral and eUSCI_B0 peripheral.

    Thanks,

    Yiding

  • Didn't make a difference and neither did quickly trying HW BSL invocation on MSP-CAPT-FR2633 (had to disconnect the Programmer/HID board. And honestly still need to hook up a scope to check RST/TEST timing. Though I2C bus analyzer clearly shows above traces when running code from flash with regular RST. Just can't seem to invoke BSL to get Mass Erase command handshake).

    Taking a different tack on this to prove I2C BSL, should I just order a MSP Target Development board for FR2633 to use with MSP-FET?

    Which MSP Target Development board is most appropriate for MSP430FR2633 ?

    (www.ti.com/.../MSP-TS430RGE24A seems close but MSP430FR2633 not available in RGE package. Can even use MSP432 as a host and MSP430FR2633 as the targeted BSL device similar to app note: www.ti.com/.../slaa755.pdf)

    Nothing on www.ti.com/.../toolssoftware specifies which board to use.
  • Working off line the http://www.ti.com/tool/Msp-Exp430Fr2433 was a better platform since RST/TEST pins more accessible.

    I was able to get into BSL (saw the blinky stop running).  But had trouble figuring out where the BSL was getting stuck (since you lose JTAG emulation/CCS when disconnecting TEST/SBWTCK on the Launchpad).


    But the original goal was SW invocation anyway:

    >>Can you try to reset the peripherals before SW entering the BSL?

     __disable_interrupt(); // disable interrupts
      ((void (*)())0x1000)(); // jump to BSL

    And since above wasn't working, looked into a SW method right after reset. Instead of trying to jam above into _c_int00_noinit_noargs_noexit in boot_special.c  (of msp430fr243x_1.c Toggle P1.0 using software) somehow, got the idea of directly writing 0x1000 into the _reset_vector   with  view->memory browser.  And it worked!

    So please see BSL I2C interaction in screenshot below


    (I started using MSPBoot_I2C_F5529 from  MSPBoot_2_00_00_01.zip   But should move to the PI from MSP432Host_UART_BSL_MSP430FR from slaa755.zip.  Much past command 0x15 needs tweaking.  But at this point below enough for as proof of concept).


**Attention** This is a public forum