MSP430F5438A-EP: Command Line Interface for Programming MSP430 Flash Memory

BSL and INFOA are just flash segments like any other flash segments from main memory. They can be unlocked by writing right value to RAM registers. So if any of TI software PC side is able to write to target device RAM, BSL and INFO A can be unlocked on this way.

Hi Zrno,

Thanks for the reply, appreciate the support. I want to erase and program the INFOA and BSL flash segments — do these commands look like they should be doing the job?

MSPFlasher:

C:\ti\MSPFlasher_1.3.20>MSP430Flasher.exe -u -b -e ERASE_ALL

UniFlash:

C:\ti\uniflash_windows>dslite.bat --mode flash -c user_files/configs/MSP430F5438A.ccxml -l user_files/settings/settings.ufsettings -s VerifyAfterProgramLoad="No verification" --before Erase

With settings file:

{"TI MSP430 USB1/MSP430":{"MSP430UnlockBSLMode":true,"MSP430DownloadOptions":"Erase main, information and protected information memory"}}

zrno soli said:

So if any of TI software PC side is able to write to target device RAM, BSL and INFO A can be unlocked on this way.

I understand that access to INFOA and the BSL flash memory should be a menial task, but the command line tools (or my invocations of the command line tools) don't seem to be doing the job. Would you be able to provide an example of how to do this using MSPFlasher or UniFlash?

Best regards,
KM

Hi,

Looking at the MSPFlasher source code for function 'StdUseCase_Erase' (StdUseCase.cpp, line 843):

void StdUseCase_Erase( sDefOptions_t* sOpt )

MSP430_Configure( LOCKED_FLASH_ACCESS, ENABLE );

MSP430_Configure( UNLOCK_BSL_MODE, ENABLE );

  /**
  \fn    STATUS_T MSP430_Erase(int32_t type, int32_t address, int32_t length);

  ...

  \note    5. Some device families have a locked INFO memory segment (INFO A).
              MSP430_Configure(LOCKED_FLASH_ACCESS,...) can be used to unlock/lock this segment.
              Having parameter 'type' set to ERASE_ALL will erase the complete INFO memory in case
              the INFO A segment was unlocked prior.
              Otherwise only INFO segments B, C and D will be erased.
  \note    6. Some device families have a lockable BSL memory segment.
              MSP430_Configure(UNLOCK_BSL_MODE,...) can be used to unlock/lock this segment.
              Having parameter 'type' set to ERASE_ALL will erase the complete BSL memory in case
              the BSL memory was unlocked prior.

  ...

  */
  DLL430_SYMBOL STATUS_T WINAPI MSP430_Erase( int32_t type, int32_t address, int32_t length );

void StdUseCase_ReadWrite( sDefOptions_t* sOpt, sRTE_t* RTE )

Ret_Configure = MSP430_Configure( LOCKED_FLASH_ACCESS, ENABLE );

...

Ret_Configure = MSP430_Configure( UNLOCK_BSL_MODE, 1 );

* -----/|-------------------------------------------------------------------- *
*     / |__                                                                   *
*    /_   /   MSP Flasher v1.3.20                                             *
*      | /                                                                    *
* -----|/-------------------------------------------------------------------- *
*
* Evaluating triggers...done

...

* Unlocking BSL memory...done
* Unlocking Info Memory A...done

...

C:\ti\MSPFlasher_1.3.20>MSP430Flasher.exe -u -b -n MSP430F5438A -w "C:\km\boardman3.hex"

1. MSPFlasher function 'StdUseCase_Erase' is missing the calls to 'MSP430_Configure' in order to unlock INFOA and/or BSL memory, as necessary.
2. Calls to 'MSP430_Configure' (e.g., MSP430_Configure( UNLOCK_BSL_MODE, ENALBE ) or MSP430_Configure( LOCKED_FLASH_ACCESS, ENABLE )) appear to be successful, but still fail in unlocking INFOA and BSL memory.

Perhaps the 'MSP430.dll' library packaged with MSPFlasher v1.3.20 is outdated? ('MSP430.dll' v3.14.0 is inside this package.) Or perhaps there's something within the 'MSP430_Configure' definition that's preventing flash unlocks for the MSP430F5438A device in particular? Hard to say without seeing the source code.

Best regards,
KM

adatakm said:

Any further insight/help with this is greatly appreciated. I really need to automate this process using a command line interface, as programming these guys manually with a GUI just doesn't scale well when you've got hundreds/thousands to get through.

This sounds like production. I know it's yet another tool, but perhaps the MSP-GANG would be helpful for you. There are several operating modes (interactive, scripts) that allow you to program multiple devices at the same time.

Hi James,

That's a neat tool — thanks for bringing that to my attention. Something to keep in mind for the not-so-distant future.

Best regards,
KM

Hi John,

Alright, now we're talking! You seem to inadvertently have figured this one out — UniFlash will only allow protected flash memory erase operations to work if you are performing a program operation within the same command.

Using a test HEX image that only targets flash byte addresses in the range of 0x5C00 -> 0x45BFF, with the same UniFlash settings as you have used, and clicking on the 'Load Image' button (instead of, e.g., the 'Mass Erase' button) will succeed in erasing INFOA and BSL flash regions.

However counter-intuitive it might seem, it's a solution, and works using UniFlash both in GUI mode and CLI mode. So thanks for the effort and all of your responses. But is there a good reason as to why the tool behaves in this way?

Best regards,
KM

KM,

I don't have access to the board today.  I should have tried mass erase yesterday.  Maybe I can reproduce on a different setup.

I would expect "Mass Erase" to erase the main, info and BSL memory.  The note says that it will.  Definitely seems like a bug.  I think you may have hit upon something in one of your earlier posts.  It could be that UniFlash is not setting the flag to allow access to BSL memory when the erase function runs even though it is set in the GUI.  i.e. maybe that flag is only associated with the download action (since it is part of that group) and not the erase one.

Let me see if I can reproduce on a different 430.

John

Ok I can see the same on a F5529 LaunchPad.

Erase happens as expected when loading.  When doing a mass erase those areas are not touched.

I filed a bug to track this: https://sir.ext.ti.com/jira/browse/EXT_EP-10607

Thanks for the effort, really appreciate it. This had been a lingering issue on my list for a while and I'm glad we're finally coming to a resolution. I can make do with a "program" + "erase" so we're all good here.

Best regards,
KM

adatakm said:

I would have taken the MSPFlasher source code and stepped-through/patched the tool myself, but the Visual Studio project packed with the tool does not build (missing libraries/unresolved symbols).

I was able to use Microsoft Visual Studio Community 2017 v15.9.39 to build / debug / modify MSP430flasher v1.3.20 without having the modify the Visual Studio project.

As well as installing Visual Studio had to install Windows SDK Version 10.0.17134.0 which the project was set to use.

Looking back at my browser history the download links were:

https://download.microsoft.com/download/5/A/0/5A08CEF4-3EC9-494A-9578-AB687E716C12/windowssdk/winsdksetup.exe?ocid=wdgcx1803-download-installer for the Windows SDK

https://download.visualstudio.microsoft.com/download/pr/653e10c9-d650-464b-a0b0-f211bb0c7c32/ced6ef5ff7cd647dd111c6104897480dea3ea29cf024fb7e3b0bc0043096ae0f/vs_Community.exe for the Visual Studio installer.

Hi Chester,

You are totally correct — when first opening the MSPFlasher MSVC project, it defaults to targeting an 'x64' build rather than an 'x86' build. Targeting an 'x86' build does indeed let me compile MSPFlasher from sources, for either debug or release. Apologies for that false-positive.

Best regards,
KM