• State TI Thinks Resolved
  • Replies 11 replies
  • Answers 2 answers
  • Subscribers 78 subscribers
  • Views 304 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

MSP430F2122: MSPFlasher.exe does not start code on completion

SteveW81
Prodigy 10 points
Part Number: MSP430F2122
Other Parts Discussed in Thread: MSP430F2232, , MSP-FET, UNIFLASH

Hi,

I have two products that I want to use MSPFlasher to program, in a new automated system rather than with the Elprotronic solution we have been using for years.

On my MSP430F2232 based system, the data is flashed in and the MSP430 starts, indicated by a flashing LED that is the first thing it does. On my MSP430F2122 based system, once in a blue moon it starts OK, again flashing LED at first start, but usually nothing. I have tried different exit specifications, VCC, RESET, VCC, RESET, etc., but nothing works. The only way to get it to work reliably is to power cycle the product the F2122 is on. This is really messing up the automation, as the next stage immediately fails if the F2122 is not ready.

I have tried a MSP-FET430UIF and a MSP-FET (V2) without success. The circuit on RST/NMI/SBWTDIO is identical on both products, and I managed to use UNIFlasher with the -u argument and the F2122 started just fine. Unfortunately getting UNIFlasher on the PC in question will be a nightmare due to the policy's in place.

Here is a log file showing everything appears to be fine, but the F2122 did not start.

on Apr 22 12:22:53 2024:	* -----/|-------------------------------------------------------------------- *
Mon Apr 22 12:22:53 2024:	*     / |__                                                                   *
Mon Apr 22 12:22:53 2024:	*    /_   /   MSP Flasher v1.3.20                                             *
Mon Apr 22 12:22:53 2024:	*      | /                                                                    *
Mon Apr 22 12:22:53 2024:	* -----|/-------------------------------------------------------------------- *
Mon Apr 22 12:22:53 2024:	*
Mon Apr 22 12:22:53 2024:	* Evaluating triggers...done
Mon Apr 22 12:22:53 2024:	* Checking for available FET debuggers: 
Mon Apr 22 12:22:53 2024:	* Found USB FET @ COM23 <- Selected
Mon Apr 22 12:22:53 2024:	* Initializing interface @ COM23...done
Mon Apr 22 12:22:53 2024:	* Setting FET speed...done
Mon Apr 22 12:22:53 2024:	* Checking firmware compatibility: 
Mon Apr 22 12:22:53 2024:	* FET firmware is up to date.
Mon Apr 22 12:22:53 2024:	* Reading FW version...done
Mon Apr 22 12:22:53 2024:	* Setting VCC to 3000 mV...done
Mon Apr 22 12:22:54 2024:	* Accessing device...done
Mon Apr 22 12:22:54 2024:	* Reading device information...done
Mon Apr 22 12:22:54 2024:	* Loading file into device...done
Mon Apr 22 12:23:04 2024:	* Verifying memory (C:\TI\test.txt)...done
Mon Apr 22 12:23:05 2024:	* 
Mon Apr 22 12:23:05 2024:	* ----------------------------------------------------------------------------
Mon Apr 22 12:23:05 2024:	* Arguments   : -i COM23 -n MSP430F2122 -e ERASE_ALL -w C:\TI\test.txt -v -z [VCC, RESET] 
Mon Apr 22 12:23:05 2024:	* ----------------------------------------------------------------------------
Mon Apr 22 12:23:05 2024:	* Driver      : loaded
Mon Apr 22 12:23:05 2024:	* Dll Version : 31400000
Mon Apr 22 12:23:05 2024:	* FwVersion   : 31200000
Mon Apr 22 12:23:05 2024:	* Interface   : COM23
Mon Apr 22 12:23:05 2024:	* HwVersion   : U 3.0
Mon Apr 22 12:23:05 2024:	* JTAG Mode   : AUTO
Mon Apr 22 12:23:05 2024:	* Device      : MSP430F2122
Mon Apr 22 12:23:05 2024:	* EEM         : Level 1, ClockCntrl 1
Mon Apr 22 12:23:05 2024:	* Erase Mode  : ERASE_ALL
Mon Apr 22 12:23:05 2024:	* Prog.File   : C:\TI\test.txt
Mon Apr 22 12:23:05 2024:	* Verified    : TRUE
Mon Apr 22 12:23:05 2024:	* BSL Unlock  : FALSE
Mon Apr 22 12:23:05 2024:	* InfoA Access: FALSE
Mon Apr 22 12:23:05 2024:	* VCC ON      : 3000 mV
Mon Apr 22 12:23:05 2024:	* ----------------------------------------------------------------------------
Mon Apr 22 12:23:05 2024:	* Resetting device (RST/NMI)...done
Mon Apr 22 12:23:06 2024:	* Starting target code execution...done
Mon Apr 22 12:23:06 2024:	* Disconnecting from device...done
Mon Apr 22 12:23:06 2024:	* 
Mon Apr 22 12:23:06 2024:	* ----------------------------------------------------------------------------
Mon Apr 22 12:23:06 2024:	* Driver      : closed (No error)
Mon Apr 22 12:23:06 2024:	* ----------------------------------------------------------------------------
Mon Apr 22 12:23:06 2024:	*/

Any Ideas?

Thanks

Steve

  • 0
    TI__Guru 62301 points

    Hi Steve,

    Regarding the device that does not reset and start after programming, can you take a look at the RST signal with an oscilloscope or logic probe and compare to another device that works fine.

  • 0 in reply to Dennis Lehman
    Prodigy 10 points

    Hi

    A side-by-side of loading the same code in to the MSP430F2122.

    Left is MSPFlasher that requires a power-cycle to get the software to run, right is using Uniflash which always starts correctly. There are definitely differences at the end of the whole sequence.

    Thanks

    Steve

  • 0 in reply to SteveW81
    TI__Guru 62301 points

    Hi Steve,

    Great captures!  Yes, I do see they are different.

    You mentioned it is not practical to install Uniflash on your PC.  There is an option to build a custom CLI install that includes all the drivers and image files, etc.  That might be a way to get it running.  Were you aware of this?

  • 0 in reply to Dennis Lehman
    Prodigy 10 points

    Yes I am aware of it, but getting the software approved to be installed on production PCs is a nightmare that takes ages due to the usual security and auditing concerns. It would really be a lot easier to have it work as advertised.

  • 0 in reply to SteveW81
    TI__Guru 62301 points

    Hi Steve,

    I completely understand with challenges to install on production PCs.

    Can you share your MSP430Flasher *.bat file?  Also, do you use the -z RESET command at the end of the programming script?  If so, see what happens if you try this as the last line:  MSP430Flasher -n MSP430F2232 -z RESET

  • 0 in reply to Dennis Lehman
    Prodigy 10 points

    Hi,

    From my first post, the arguments used are

     

    Arguments   : -i COM23 -n MSP430F2122 -e ERASE_ALL -w C:\TI\test.txt -v -z [VCC, RESET]

    I also tried doing a second call to MSPFlasher.exe with just the reset command (all combinations i.e. VCC, RESET, VCC & RESET). None of it worked. From the screen shots, it looks like MSPFlasher is operating the RST line differently than Uniflash

  • 0 in reply to SteveW81
    TI__Guru 62301 points

    Hi Steve,

    Sorry - I missed the arguments in the snippet you provided earlier.

    To your point, and it appears to be true, the RST is handled differently.

    I wasn't sure if calling a second time with only the RST would be enough to control the pin.  Did you verify with a scope or logic probe if the RST pin toggles on the second call?

  • 0 in reply to Dennis Lehman
    Prodigy 10 points

    I did not specifically verify it, but the first thing the code does is flash an LED, which does not flash when I have this issue (same behaviour as the previous RST grab)

  • 0 in reply to SteveW81
    TI__Guru 62301 points

    Hi Steve.

    Ok, at this point I'll have to take a look at the source code for MSP430 Flasher to see if it is possible to patch a solution.  The team that developed this years ago was based in Germany so I won't have anyone to reach out to going forward.  Give me a day or 2 to work on this.

  • 0 in reply to Dennis Lehman
    Prodigy 10 points

    Thanks

    If they are picking this up again an updated library would be good, so it can be compiled on some recent Linux versions. I believe the libraries used are from the 2018 era and not available on current distros.

    Plus some ARM64/AArch64 support would be fantastic, as lot of complexity in production set-ups could be avoided if MPS430Flasher would run on a recent RaspberryPi, using direct GPIO control of hardware testers, and the expected Compute Module 5. I would also not be surprised if we start seeing lower cost mini/embedded PCs running the new SnapDragon or equivalent CPUs.

  • 0 in reply to SteveW81
    TI__Guru 62301 points

    Hi Steve,

    I do apologize for not responding earlier.  I'm being told that MSP430 Flasher is deprecated.  This means there will be no future support (adding/modifying code features, etc., unless there is a major bug fix required).  Customers are pointed to our Uniflash, which is fully supported by a dedicated team.

**Attention** This is a public forum