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.

MSP430F5659: Not Executing After Flashing Using MSP430 USB Firmware Upgrade

Part Number: MSP430F5659
Other Parts Discussed in Thread: MSP-FET, TEST2

Hi All,

We are facing some flashing related issue in a custom board of MSP430F5659. MCU flashed using MSP430 USB Firmware Upgrade V1.3.1, the TI-TXT file generated using CCS.

After Flashing it wont executing. We flashed the same using MSP-FET 430 JTAG in CCS but it works fine.

What might be the reasons for USB Firmware Upgrade wont work ?

Attaching the log of USB Firmware Upgrade :-

""" Starting
Password Sent Successfully
Sending RAM BSL v00.07.08.38
Done RAM BSL v00.07.08.38
Erasing memory segments  
Sending C:\Users\name\Desktop\Application_test2.txt
Firmware Sent
Verifying memory
Memory successfully verified
Total programming time is 2s  
Resetting Device...
Starting application
Done! """

Is the issue related to Boot Loader Version ? How can flash the Boot Loader to MCU ?

If the Boot Loader version changed can it reverted to old version ?

While Flashing  Boot Loader , if a power failure is occurred can we revert it to back ?

Kindly Help !

Regards,

Renjith

  • Hi Renjith,

    Your version of MSP430 USB Firmware Upgrade (V1.3.1) is too old. Please download the latest MSP430 USB Developers Package and try the strongly recommended Python-based MSP430 USB Firmware Upgrade (V3.1). You can find it at the path:

    MSP430USBDevelopersPackage_VERSION\Host_USB_Software\Python_Firmware_Upgrader\Python_Firmware_UpgraderGUI.exe

    Meanwhile, please also make sure the USB BSL is correctly invoked.

  • Hi Philo ,


    Thank You for your quick response.. Now flashing is works fine and executed for one time only.

    If i reset or power off the MCU, then it wont work again ..!

    Help please !


    Regards,
    Renjith

  • Hi ,

    Any Upadate on this ??

    Regards,
    Renjith
  • Hi Renjith,

    So the USB BSL is actually working well. It sounds like the code is lost after power-off. Please check the following:
    1. If you program the MSP430 with MSP-FET in CCS, and then also power-off, does it work after that?
    2. Check if your code is correctly allocated in the non-volatile memory (Flash) area.
    3. If necessary, maybe you can upload your whole CCS project so that I could take a look and identify the possible problems.

  • RELAY_CONTROL.zipHi

    1) It works fine if  it flashed using MSP-FET in CCS.

    2) It works on default setting of CCS, I didn't change any. How to properly allocate code in Flash area?

    3) I am using a simple program for testing this, just toggele a GPIO pin. I am also uploading the CCS project.

    Regars,

    Renjith

  • Hi Renjith,

    Some further questions for more details:
    1. By "not working" do you mean that the P5.3 is not toggling?
    2. Try adding the following line of code after the line that stops the watchdog timer:
    PM5CTL0 &= ~LOCKLPM5; // Disable the GPIO power-on default high-impedance mode to activate previously configured port settings
    3. If you have instruments to check the waveform, can you check if the XT2 oscillator is working well after the power cycle?
  • Hi

    Thank you verymuch for your quick responses.

    1) yeah, i mean p5.3 is not toggling
    2) if i add this code PM5CTL0 &= ~LOCKLPM5; its not even working in CCS.
    3) I tried without init the crystals, it also hav the same result.. We alredy verified the XT2
    4) How to configure flash locations in CCS ?

    Regards,
    Renjith
  • Hi Renjith,

    Your code is allocated in Flash by default. I suppose that is not our main issue now.
    If it doesn't even work in CCS, then please check where does the program go. It might be unable to get out of the do-while loop, which probably means that XT2 is actually not working.

    It would be also helpful if you can check the content of UCSCTL7 and SFRIFG1 registers.

  • Hi

    while executing PM5CTL0 &= ~LOCKLPM5 step by step in CCS,

    it first shows a warning message like this :-
    "Break at address "0xfffa" with no debug information available, or outside of program code."

    Then goes to this functions :-

    CSTART_DECL _c_int00_noinit_noargs(void)
    {
    _c_int00_template(0, 0, 0);
    }
    then ,
    int _system_pre_init(void)
    {
    return 1;
    }
    then return to main(0);
    This process is repeating.

    UCSCTL7 = 0x0403
    SFRIFG1 = 0x00C2


    Regards,
    Renjith
  • Hi Renjith,

    So it is not stuck in the do-while loop. It now looks like it's been reset after executing PM5CTL0 &= ~LOCKLPM5 step and it might have something to do with the circuit on your custom board.
    If you have a launchpad or TI official target board, please try your code on those boards. With this comparison, it might be able to confirm that your code is clean and the problem is on your custom board.
  • Hello

    Thank you Very Much for your quick support.
    Currently we don't have any TI target board.
    Is there any other option to confirm this... ?
    What might be the issue with hardware ?

    Regards,
    Renjith
  • Hi Renjith,

    Hardware issues could be various and I am sorry that I cannot offer more help online. I could only suggest you debug with comparison. Be bold to try different configurations and try to focus on the differences between the configuration that makes things work and other configurations that don't work.

    For example, try to restore your code to the version that worked. Then try to run it in CCS step by step. Observe the value of configured registers and see if everything is as expected.

    Please kindly try more and let me know if you have new findings. Still, the best approach would be to get a TI board for tests in comparison with your custom board.

    P.S. it might be helpful to check the difference between your custom board and TI official target board.

  • Hi

    Thankyu For your support..
    The Issue is resolved , Actually its related to hardware, PUR pin was always high. That was the reason.

    With Best Regards,
    Renjith

**Attention** This is a public forum