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.

How to Fix MSP430 ISR locations?

Other Parts Discussed in Thread: MSP430F5529

Hello,

We are using USB BSL to update MSP430F5529 firmware.
We want to add/update a small part of data to the present firmware.

But the problem is the BSL automatically performs a mass erase,
we understood that the BSL password reside at addresses 0xFFE0 to 0xFFFF
which changes for every new program.

The Appl note(SLAA452B) mentions that Fixing the ISR locations solves this problem.
But we don't know how exactly do we Fix the ISR..

Could you please let me know if there is a reference or example code on Fixing the ISR locations.

Regards
kummi

  • Hi,

    I found the way to FIX the ISR locations.

    But unfortunately, TI's firmware update software (BSL_USB_GUI.exe)
    is executing MASS ERASE everytime....

    It shows "Mass erase occured!" message everytime,
    even though if we program the same program(which has same ISR data).

    Please let us know if there is any way to avoid Mass Erase,
    we want to update only INFO Memory data.

    Regards

  • Hi Kummi,

    Do you know which firmware update software you are using? It sounds like it is one of the GUIs.

    The BSL itself supports not doing a mass erase - and you will also need to provide the correct password using the correct command in order for the mass erase not to happen.

    I would recommend using the BSL_Scripter.exe instead. This allows you to create a small txt file that has a list of the exact commands you want the BSL host to perform, so that you can configure the host to do exactly what you want. There are example scripts for F5529 included as well. Please see www.ti.com/lit/zip/slau319 and www.ti.com/lit/pdf/slau319 for more information about communicating with the BSL. The BSL scripter is found in that zip file under BSL_Files/BSL Scripter, you'll see BSL_Scripter.exe. You'll also find in the same directory a Demo Scripts folder, where you should look at the one for F5529. Note that you'll need to change the password that it is sending wiht the RX_PASSWORD command to match the correct password for your txt file that you've already loaded into the part.

    I hope this helps to get you started.

    Regards,

    Katie

  • Hi

    Thank you,

    I am using MSP430_USB_Firmware_Upgrade_Example-1.3.1.1 downloaded from the below site.
    http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSP430_USB_Developers_Package/latest/index_FDS.html

    BSL_Scripter.exe is a command line and we would prefer
    GUI to reduce the time to setup.

    In case of MSP430 BSL we understand that, it is required to provide the correct password.

    But the the above GUI software don't have the option to provide password,
    and as mentioned in my first post, this GUI do MASS Erase everytime
    even though if program the same firmware(same vector=same password) present in the MSP430 flash.

    We believe this is the problem of the GUI.
    If TI could change this limitation of the GUI, tt would be very helpful for many of our customers.

    Best Regards.
    Kummi

  • Hi,

    We were able to modify the GUI to avoid mass erase by modifying "DownloadView.cpp"
    file in the BSL_USB_GUI source code in the below folder.

    C:\ti\msp430\MSP430 USB Firmware Upgrade Example\SourceCode\BSL_USB_GUI

    But, we have one more problem with this GUI.
    As we use this GUI to program many MSP430 devices, we need to reduce the programming time.

    Looking into the source code DownloadView.cpp, we found that, after sending the
    RAM BSL, it executes a delay of 3 seconds as shown below.
    We would like to know what is the purpose of this delay and is it possible to remove this delay?

    from DownloadView.cpp:
    ---------------------------------------------------
    // Send RAM BSL
    worker->ReportProgress(20,"Sending RAM BSL v" + resources->GetString(L"RAM_BSL_VERSION") + "\r\n");
    BSL_RX_TXT((char *) RAM_BSL, 1);
    BSL_LoadPC(0x2504);
    worker->ReportProgress(30,"Done RAM BSL v" + resources->GetString(L"RAM_BSL_VERSION") + "\r\n");

    // Close BSL connection
    BSL_close_BSL();

    worker->ReportProgress(35,"");
    Sleep(1000);
    worker->ReportProgress(40,"");
    Sleep(1000);
    worker->ReportProgress(45,"");
    Sleep(1000);
    ---------------------------------------------------------------

    Note: We tried to remove this delay, but without this delay we get error in the programming.
              so we believe this delay is necessary, but don't know why this delay is necessary?

    Please let us know if there is any other ways to reduce the programming time using USB BSL GUI?

    Best Regards
    kummi

  • Hi,

    I found the reason for this necessary additional delay.

    It seems, after downloading the RAM BSL, the USB is re-enumerated with the RAM BSL
    and the delay (3 seconds) is meant for this USB re-enumerated.
    Note: this is same for BSL_Scripter.exe also

    Please let me know if my understanding is correct?

    Regards
    kummi

  • Hi Kummi,

    Kummi said:

    It seems, after downloading the RAM BSL, the USB is re-enumerated with the RAM BSL
    and the delay (3 seconds) is meant for this USB re-enumerated.
    Note: this is same for BSL_Scripter.exe also

    Please let me know if my understanding is correct?

    Yes, the delay is to allow the BSL to re-enumerate after the RAM BSL is loaded and started.

    The GUI is provided as an example, not really as a final production tool. This is part of why we provide source code for it (as well as the BSL Scripter source and the python GUI source) - so that you can modify it to suit your needs or use it as an example for your own BSL host.

    Regards,

    Katie

**Attention** This is a public forum