• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 78 subscribers
  • Views 878 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.

Original question:

MSP430FR2422: BSL software for Android

MSP430FR2422: Updating Firmware over I2C BSL

Travis Ray
Prodigy 80 points
Part Number: MSP430FR2422

Hi, I'm working firmware for a support board that is attached to a Raspberry Pi. I have some existing I2C code that communicates with the MSP430FR2422 and the Pi. Now I'm trying to get the I2C BSL sorted out. I've modified my code to the follow to test the BSL:

int main(void){
  WDTCTL = WDTPW | WDTHOLD;             //Stop watchdog timer to prevent time out reset
  PM5CTL0 &= ~LOCKLPM5;                 //Disable the GPIO power-on default high-impedance mode to activate // previously configured port settings
  
  __bic_SR_register(GIE);               //Clear GIE
  ((void (*)())0x1000)();               //Jump to BSL
}

Running:

pi@raspberrypi:~ $ i2cdetect -y 1


     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

I've complied the TI example tool from msp430_i2c_bsl_linux_tools_v1_00_00_00.zip and I get the following:

pi@raspberrypi:~/i2c_test/bsl $ ./msp430-i2cbsl-tool -f firmware.txt -i /dev/i2c-1 -s 0x48

---------------------------------------------------------------
   TI MSP430 I2C Linux BootLoader 01.00.00.00
---------------------------------------------------------------
INFO: Firmware file firmware.txt specified
INFO: I2C BUS /dev/i2c-1 specified
INFO: Slave address 0x48 specified
INFO: Opening TI-TXT firmware file firmware.txt...  done!
INFO: Password file not found, defaulting to 0xFFs.
INFO: Invoking BSL (Attempt 1)... Invoke sent!
INFO: Delaying for 2 seconds to wait for invoke... done!
INFO: Attempting to unlocking device with password... Fail!
INFO: Device could not be unlocked. Resetting password and trying again.
INFO: Invoking BSL (Attempt 2)... Invoke sent!
INFO: Delaying for 2 seconds to wait for invoke... done!
INFO: Attempting to unlocking device with password... Fail!
INFO: Device could not be unlocked. Resetting password and trying again.
INFO: Invoking BSL (Attempt 3)... Invoke sent!
INFO: Delaying for 2 seconds to wait for invoke... done!
INFO: Attempting to unlocking device with password... Fail!
INFO: Device could not be unlocked. Resetting password and trying again.
INFO: Invoking BSL (Attempt 4)... Invoke sent!
INFO: Delaying for 2 seconds to wait for invoke... done!
INFO: Attempting to unlocking device with password... Fail!
INFO: Device could not be unlocked. Resetting password and trying again.

ERROR: When trying to invoke or unlock device (Response code 0x104).

I've been poking at the for a couple of hours now. I'm really not sure where the issue is. Any suggestions?!?

  • 0
    TI__Mastermind 49692 points

    Hi Travis,

    Thanks for your post. I'm looking into it and should have some initial feedback for you by next Monday.

    Regards,

    James

  • 0
    TI__Mastermind 49692 points

    Hi Travis,

    Thanks for your patience.

    After digging into this, I initially thought that the BSL invocation process from the host (RPi) was not working correctly, resulting in the Response code 0x104. The BSL invocation method can be done via hardware or software. However, since you're able to see the slave address using the "i2cdetect" command, the invocation process seems to be working at that stage. Here's a similar thread where the software invocation seemed to allow the address to show up.

    Linux/MSP430FR2633: Problem with update FW via I2C

    Here's a helpful excerpt from the MSP430™ Firmware Updates Over I2C Using Linux application report:

    Another important design requirement of performing a BSL update is having a method to invoke the BSL mode on the MSP430 device. For MSP430, the following are ways to invoke the BSL: hardware invocation and software invocation. Hardware invocation requires the user to apply a specific timing pulse to the TEST and RESET pins. Software invocation requires the user to have a custom I 2C command handler that changes the program counter to enter BSL mode. For specifics on software and hardware BSL invocations, see the specific BSL design guide (see MSP430FR57xx, MSP430FR58xx, MSP430FR59xx, MSP430FR68xx, and MSP430FR69xx Bootloader (BSL) User's Guide [SLAU550]). For hardware invocation, the timing pulse must be applied on the TEST and RESET pins before calling the terminal application. If the hardware invocation is used, specify the –n option to omit the software invocation. If the –n flag is not specified before any BSL command is issued, the terminal program sends an I 2C write transaction of the bytes specified in the invokeString array of the main.c file. By default, this invoke string is represented by a character sequence of {0xCA, 0xFE, 0xDE, 0xAD, 0xBE, 0xEF, 0xBA, 0xBE}.

    What I think is happening is the slave device (programmed with the firmware you shared above) is invoking the BSL itself via software. Then, when your RPi is trying to invoke the BSL again, there's an error since it's already been invoked.

    Regards,

    James

  • 0 in reply to James Evans
    Prodigy 80 points

    It sounds like the -n option should skip the invocation and start a BSL update. But I get pretty similar results.

    pi@raspberrypi:~/i2c_test/bsl $ ./msp430-i2cbsl-tool -f firmware.txt -i /dev/i2c-1 -s 0x48 -n

---------------------------------------------------------------
   TI MSP430 I2C Linux BootLoader 01.00.00.00
---------------------------------------------------------------
INFO: Firmware file firmware.txt specified
INFO: I2C BUS /dev/i2c-1 specified
INFO: Slave address 0x48 specified
INFO: Opening TI-TXT firmware file firmware.txt...  done!
INFO: Password file not found, defaulting to 0xFFs.
INFO: Skipped software invoke.
INFO: Attempting to unlocking device with password... Fail!
INFO: Device could not be unlocked. Resetting password and trying again.
INFO: Skipped software invoke.
INFO: Attempting to unlocking device with password... Fail!
INFO: Device could not be unlocked. Resetting password and trying again.
INFO: Skipped software invoke.
INFO: Attempting to unlocking device with password... Fail!
INFO: Device could not be unlocked. Resetting password and trying again.
INFO: Skipped software invoke.
INFO: Attempting to unlocking device with password... Fail!
INFO: Device could not be unlocked. Resetting password and trying again.

ERROR: When trying to invoke or unlock device (Response code 0x104).


    Unless I'm missing something it should work like that. Let me know if I'm wrong. When I get a chance I'll try adding the invocation trigger to my normal FW to allow the "typical" programming. Even if this works I'll still have the problem of not being able to program a new MSP from the Pi (which is one of my goals with this).

  • 0 in reply to Travis Ray
    TI__Mastermind 49692 points

    Hi Travis,

    I was reading through the MSP430 FRAM Devices Bootloader (BSL) User's Guide and found Section 3.4 BSL Time-out Feature.

    The BSL on the FR26xx, FR25xx, FR24xx, and FR23xx MCUs implements a low-power time-out feature for the automatic detection of the BSL interface. If no communication has been established within ten seconds, the device enters LPM4 mode. To invoke the BSL again, the device power must be cycled, or a reset or NMI must be received.

    Do you know if you're sending these commands within the 10 second window? Perhaps that's why the communication is failing.

    Also, since you'd like to program new (blank) MSP430 devices, then you may not need the BSL entry sequence according to Section 3.3.3 Blank Device Detection.

    The boot code on the FR26xx, FR25xx, FR24xx, and FR23xx MCUs supports blank device detection to avoid the BSL entry sequence. This saves time and also eliminates the need for two additional wires (TEST, RST) for the BSL invocation sequence. The BSL entry sequence can be bypassed when the blank detection is enabled. The device jumps directly to the BSL and bypasses the entry sequence only when the reset vector has a value of 0xFFFF.

    Regards,

    James

**Attention** This is a public forum