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 Perform Segment Erase using MSP430 USB Firmware Upgrade Example v1.3.0

Hello,

I have the requirement to upgrade the firmware, using Segment Erase. I am trying with MSP430 USB Firmware Upgrade Example v1.3.0 tool but am unable to upgrade. Can you please explain the step wise procedure for that?

Thanks in advance,

Deep

  • Hi,

    The tool you mentioned has the ability to perform segment erase.

    If the password supplied in password.Text field at Firmware.resx file matches corresponding value of your old firmware, only segments necessary for flashing new firmware will be erased.

    If the password does not match, bulk erase is performed (all flash memory segments are erased) even though your new firmware has only 1 segment in size.

    The password as you are probably aware uses as its value 16 words in MSP430 vectors area.

    You'll need to re-compile the MSP430 USB Firmware Upgrade Example v1.3.0 code with the new password. 

    BTW, there is newer version of the tool available, 1.3.1, at TI website, which fixes several bugs.

  • Hello Serge,

    Thanks for your response! It worked with the demo '5529_LED_BLINK.txt' file. Further to this I have following two queries....

    1. Now I want to upgrade the firmware, with my project output txt file but in my txt output file there is no password generated. Below is the snap shot of mt txt file, having no password

    I need your help to generate the password for my output txt file...

    2. According to section 3.4 BSL Password inside slaa452b.pdf I can fix the BSL password by fixing the ISR locations. I need your support to do this.

    Thanks in advance,

    Deep

  • Hi Deep,

    1. The snapshot you've provided does not have any clues of where the password is. Normally it starts at address FFE0 and occupies 32 bytes up to address FFFF. Do you have at your firmware .txt file some labels with addresses (like @ffca, for example) ? You'll need somehow locate area FFE0...FFFF in your .txt file

    2. Because of password is located at the flash area where the interrupt vectors are located, every time you change your firmware there is a chance that this area gets changed as well. So the password as well, and you'll have to keep track of the password changes, otherwise while upgrading the firmware if you enter the password which is not valid any more bulk erase occurs wiping out all of your flash including the segments that you may use as a parameters storage and want to be preserved...

    The document you mentioned (slaa452b)  means that fixed address values are assigned to 16 vectors located in FFE0...FFFF area, and this addresses point to entries in a jump table. This table has 16 entries, each entry has a jump instruction to corresponding ISR. This table is located at fixed location in memory, so when you change your ISRs, the table entries are changed, but not the table location, so the FFE0...FFFF area is not changed and password stays fixed.

    There is a simpler way: specify 'location' pragmas for your ISRs, which places ISRs at fixed addresses in memory. But what if in new revision of your firmware your ISR(s) change in size? You'll have to change 'fixed' addresses breaking password consistency again...

    The issue with BSL password is so annoying, that for the projects which must have an option to preserve specified flash segments no matter what (they can contain factory calibration data, for example; lost of this data means sending product back to the factory for re-calibration) the custom BSL creation can be considered. The custom BSL can either disable password completely, or move it to the area when it can not clash with IRQ vectors.

  • Hello Serge,

    Thanks again for your response!

    1. I am able to find the password now.

    2. Acoording to your reply I could fix the adresses of all the ISRs used in my code apart from '_c_int00_noexit'. I tried to fix its adress in many ways but was unable to do so.

    Can you please tell me, how to fix the adress of '_c_int00_noexit'?

    Thanks in advance,

    Deep

  • Hi Deep,

    For IAR toolchain address of the program entry point is usually fixed to the value of 0x8000, which is usually start of the flash for many MSP430 devices. Though it is not necessary, it could be any other address within first 64KB of flash area convenient for your application.

    For CCS in order to do that, you'll need to edit your linker script .cmd  file, for example, like this:

    /****************************************************************************/

    /* SPECIFY THE SECTIONS ALLOCATION INTO MEMORY                              */

    /****************************************************************************/

    SECTIONS

    {

        .bss        : {} > RAM                /* GLOBAL & STATIC VARS              */

        .data       : {} > RAM                /* GLOBAL & STATIC VARS              */

        .sysmem     : {} > RAM                /* DYNAMIC MEMORY ALLOCATION AREA    */

        .stack      : {} > RAM (HIGH)         /* SOFTWARE SYSTEM STACK             */

        .text:_isr:_c_int00_noexit : {} > 0x8000 /* Entry point abs. address */

        .text       : {}>> FLASH | FLASH2     /* CODE                              */

        .text:_isr  : {} > FLASH              /* ISR CODE SPACE                    */

    . . .

    Best regards,

    Serge

  • Hello Serge,

    Thank you very much for you support!

    Best Regards,

    Deep

  • Hello Serge,

    If I change the address of the program entry point as you explained above (.text:_isr:_c_int00_noexit : {} > 0x8000 /* Entry point abs. address */ ::in CCS), it says No Source available for main(), while starting the debugger . Below is the screen shot attached.

    Can you please help me to solve this.....

    Thanks & Regards,

    Deep

  • Hi Deep,

    Are you sure you compiled 'debug' version for all files included in the project?

    You can also try solution described here:

    http://e2e.ti.com/support/microcontrollers/msp430/f/166/p/223126/790965.aspx#790965

    As far as I remember, similar problem has been discussed here in the past. Search for 'no source available' on this forum; there are several threads exist.

  • Hi Serge,

    Yes, I compiled the 'Debug' version.

    I looked around many threads and tried to fix it but could not resolve it. It was the same behavior even after I entered "_c_int00" as entry point in MSP430 Linker options. Can we resolve it?

    My another query is, if I do not fix the entry point address (.text:_isr:_c_int00_noexit : {} > 0x00009400), is there a guaranty that the BSL password for FW upgrade will not change, provided all other ISR addresses are fixed?

    Regards,

    Deep

  • Hi Deep,

    > My another query is, if I do not fix the entry point address (.text:_isr:_c_int00_noexit : {} > 0x00009400), is there a guaranty that the BSL password for FW upgrade will not change, provided all other ISR addresses are fixed?

    SA: The answer is NO. If you remove this line from linker .cmd file and compile, in your .map file you'll see that CCS linker places .const section at the beginning of the flash, and the rest of the code - including _c_int00_noexit() - after it. So if in upgraded firmware you've changed the number or size of const variables - which is absolutely normal thing - the password will be different.

    Did you try to run debugger on the version of your firmware with the above mentioned line commented out? Did it debug OK, without the error?

  • Hello Serge,

    Answer to you question > if I comment the said line, it did debug without any errors but with this line the problem occures (No source available for main().. ).

    Regards,

    Deep

  • It is strange, as this line is definitely valid one and does not produce any warnings/errors during compilation/linking.

    I mostly work with IAR toolchain which does not have this problem.

    You may have to start separate thread on this forum with this particular question; someone from CCS team will be able to explain what is wrong with the debugger settings...

**Attention** This is a public forum