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.

Automating Flash programming with SmartRFProgConsole.exe

Other Parts Discussed in Thread: CC2540

I integrating a production test solution for a BLE using CC2540.  The process involves Flashing the device with  a CC Debugger.

There is very limited documentation on using SmartRFProgConsole.exe command line parameters

Texas Instruments SmartRF Flash Programmer v1.13.7-no-mfc
---------------------------------------------------------

SmartRFProgConsole [Target][Actions][File][Interface Slow][Change / IEEE address][Flash lock][Bootloader ID]
The order of the parameters is irrelevant.

Target: [S][AU][AS][B]
S     System-on-Chip (programmed via USB)
      Type S(n), where n is the board ID number, to select a specific EB.
      Otherwise, if there are multiple boards, the one to be programmed will be
      selected at random.
AU    EB application (programmed via USB)
      Type AU(n), where n is the board ID number, to select a specific EB.
      Otherwise, if there are multiple boards, the one to be programmed will be
      selected at random.
AS(n) EB application (programmed via the EC2 adapter on serial port COMn).
      (only SmartRF04EB)
B(n)  EB bootloader (programmed via the EC2 adapter on serial port COMn).
      (only SmartRF04EB)

Actions to perform: [P][EP][EPV][EPVC][PV][PVC][V][R][RP][EP][WP][CE]
P     Program                                                  (all targets)
EP    Erase and program                                        (all targets)
EPV   Erase, program and verify                                (all targets)
EPVC  Erase, program and verify (CRC each page=>faster)        (only target S)
PV    Program (append) and verify                              (only target S)
PVC   Program and verify (CRC each page=>faster)               (only target S)
V     Verify against hex or hem file                         (targets S, AS, B)
VC    Verify against hex or hem file (CRC each page=>faster) (targets S, AS, B)
R     Read into hex file                                       (only target S)
RP=   Read flash page into binary file                         (only target S)
EP=   Erase flash page                                         (only target S)
WP=   Write flash page from binary file                        (only target S)
EWP=  Erase and Write flash page from binary file              (only target S)
CE    Full chip erase                                          (only target S)

File: F="f"
"f"   Flash image file name (intel hex file (*.hex), or hex merge file (*.hem))
      A merge file can contain one or more file/change specifications. 
      See "example.hem" for how to create one.

Interface Slow(Target = S): [IS]
IS    Program SoC (System on chip) with reduced speed on the debug interface. 

Change hex file before programming (e.g. for serial number): [A=a,D=d][EKF="f"]
A=a,D=d     Change one or more bytes in the hex file before downloading it.
a     Hexadecimal address (e.g. 2C03, 01BC25)
d     One or more bytes to be changed, in hexadecimal format, separated with
      dots (e.g. 4B, 1.2.3.A.B.C, 12.34.56.AB.CD.EF or 12.3.AB)
EKF   Patch hex file with Encryption Key data.
"f"   Certificate file from Certicom with encryption key data.

IEEE MAC address related options [KI(F=f)] [RI(F=f,[PRI][SEC])] [WI(F=f,I=i)]
(only CC243x, CC253x and CC254x)
KI(F=f)     Keep the IEEE MAC address currently on the chip when programming it
RI(F=f,[PRI][SEC]) Read out the IEEE MAC address currently on the chip
       For devices with both a primary and a secondary address, the option "PRI"       or "SEC" can be used to specify which to read. "PRI" is default.
WI(F=f,I=i) Write the given IEEE MAC address to the chip when programming it
f     The chip's flash size in kB (only used for CC243x)
      CC243x:  32, 64, or 128  (determines the location of the IEEE address)
      CC253x, CC254x:  set to 0        (not used)
i     IEEE MAC address to write in hexadecimal format, separated
      with dots (e.g. 00.12.4B.00.00.00.00.01).
      8 bytes for CC243x and CC253x, and 6 bytes for CC254x.

Flash lock (Target = S): [L(c)][LB(c)][LD(c)][LA(c)][LP(x-y)][LD][LPD(x-y)]
"L(c), LB(c), LD(c), LA(c)" only CC243x, cc111x and CC251x. "LP(x-y), LD, LPD(x-y)" only CC253x and CC254x
c     Code for write protection of the upper section of the flash:
      CC111x, CC251x: 0=All, 1=24 kB, 16 kB,  8 kB, 4 kB, 2 kB, 1 kB, 7=None
      CC2430, CC2431: 0=All, 1=64 kB, 32 kB, 16 kB, 8 kB, 4 kB, 2 kB, 7=None
L(c)     Write protect section only (L(7) is equal to omitting this parameter)
LB(c)    Write protect section + boot block
LD(c)    Write protect section, and block debug commands
LA(c)    Write protect section + boot block, and block debug commands
LP(x-y)  Write protect flash pages from page x to page y.
         Several ranges can be given separated with a comma:
         E.g. LP(0-26,48-126), LP(0,1,2,8-10).
LD       Block debug commands
LPD(x-y) Write protect flash pages and block debug commands.

Bootloader ID (Target = B): I=i
i     Becomes the EB ID number when programming new bootloader. Use 1-4 digits 
      (e.g. 0123, 3, or 45). Important: EBs that are used on the same computer
      must have unique ID numbers!

Read/Erase/Write Flash page options: RP=n, EWP=n, WP=n, EP=n
n     The Page number

Examples:
SmartRFProgConsole S EPV F=C:\test.hex A=135,D="1 23 45"
SmartRFProgConsole S P F="C:\test.hex"
SmartRFProgConsole EPV AU(0123) F=D:\Test.hex
SmartRFProgConsole B(1) EPV "F=C:\Filename with spaces.hex" I=1234
SmartRFProgConsole S EP F="C:\Test flash lock.hex" LB(3)
SmartRFProgConsole S EP F="C:\Test flash lock.hex" LD
SmartRFProgConsole S EP F="C:\Test flash lock.hex" LP(0-126)
SmartRFProgConsole S EP F="C:\Test flash lock.hex" LPD(0-126)
SmartRFProgConsole S EPV F="C:\test.hex" WI(F=0,I=00.12.4B.00.00.00.00.01)
SmartRFProgConsole S EPV F="C:\test.hex" KI(F=1)
SmartRFProgConsole S EPV F="C:\test.hex" EKF=certificate_example.txt
SmartRFProgConsole S PVC F="C:\test.hex"
SmartRFProgConsole S RP=1 F="C:\test.bin"
SmartRFProgConsole S EP=1
SmartRFProgConsole S WP=1 F="C:\test.bin"
SmartRFProgConsole S EWP=1 F="C:\test.bin"

To list all connected EBs/programmers (max 64):
SmartRFProgConsole X

Status messages are printed to stdout, error messages to stderr.

Return Codes:
      0 = Success
      1 = System error
      2 = Parameter error
      3 = Illegal parameter combinations
      4 = Missing parameters
      5 = Missing image file or communication error

Frankly, that's about as clear as mud to a new user!  And there are some obfuscations on the reuse of keys.

For example: "f" may mean full file name, Certificate File, or the chip Flash size (In kB) but only on certain targets.

Their has got to be a more complete user's guide to aid test integators somewhere.  Where is it?

  • I finally figured out how to READ the IEEE Mac Addresses. But, How would you structure the CLI to:
    Erase Program Verify keeping the PRI MAC And writing a new SEC MAC?
    Something like S(0001) EPV F="My.hex" KI(F0) WI(F=0,I=00.12.4B.00.00.00,SEC)

    Adding to that, "S(0001) WI(F=0,SECI,I=hh.hh.hh.hh.hh.hh)" returns


    Texas Instruments SmartRF Flash Programmer v1.13.7-no-mfc
    ---------------------------------------------------------

    No actions have been specified

  • Hi,
    Your command is correct, except that the "SEC" should be removed, as you are only allowed to write the secondary mac address and not the primary. So the command will be "S(0001) EPV F="My.hex" KI(F0) WI(F=0,I=00.12.4B.00.00.00)".

    You are only allowed to write a new mac address together with a file, so that's the reason why your second command is not doing anything.

    Regards,
    Ida
  • Thank you for explaining that.  Of Course, if that was documented anywhere, ... (enough said) , you guys at TI WILL fix that right?

    Now, if I can only write the SEC MAC is the "KI(F=0)"  needed or should that be removed?

  • I agree that the documentation could have been better, so we'll keep your comments in mind.

    Yes, you can remove the keep command. 

    Regards,

    Ida

  • <Rant ON>

    Yes, the documentation could be better.  What is the SR# or CAR on that and when will it be fixed?  Or, should I tell my clients to "Avoid TI Products?" for mass mfg?

    Jeff Bohrer -NI CLC, NI CLD, NI LabVIEW Champion

    Owner - 8-Ball Consulting ( a NI Alliance Partner)

    Get it, MFG Test is "BIG" documenting your tools is CRITICAL to "Time to market" TI cannot afford to continue making these errors in documentation!

    When a large company publishes any SW tool's primary documentation  (Tools they made!) VIA a windows command line stout !!! Yes  "Standard Out (As String!)"!!!!   you hope that company will still be in business before the end of product life you are producing with those tools.  I Know the product is inovative.   The TI component is innovative.  But, can marketable products be introduced without DFx? (Design For TEST comes to mind) using TI products with the DFT tools absent in documentation or completness?  Yes, I can hire a "User" to press the "Reset Button" on a CC Debugger 10,000 times per shift year- the MTBF on those buttons is what? or can you provide an automated reset in your CLI? .. sw_redetect.exe [an unpublished and undocumented utillity] only supports a maximum of 5 CC Debuggers - the StupidRFProgConsole.. oops "SmartRFProgConsole" supports 64 devices.  Who wrote the SW Specs? I want to make sure they never work for 8-Ball Consulting!

    Get your act together.

    </Rant>

    I hope that, that "constructive criticism" goes to someone who wants to keep TI profitable.  My humble opinion won't make a darned difference... but what do YOU think of SW Engineers that won't publish a help file?... Obsolete practice in documentation leads to obsolete entries on YOUR resume.... and you will need to update your resume if TI cannot update its documentation standards.

  • Have you seen the user manual for the GUI version? www.ti.com/.../getliterature.tsp

    It will be helpful to understand the command line options better.
  • Yes, I have read this section
    "6 Command Line Interface
    6.1 Options
    To get all available options in the command line interface, run the SmartRFProgConsole.exe in a
    command window without any parameters/arguments. A list of all available options will then be printed
    out. "

    I have even done that and reposted the results.
    Then I ranted about "SW Documentation (If you can call it that)" provided only VIA a cmd window stout. with an attached text file from the cmd window redirected through a third party's interface (IAR Systems?)

    Now, What will that GUI do for automated test? Should I just "Prompt the user to launch an application, select a toilet-paper roll full of (non-localized) keys, punch a bunch of (non-localized) menu options and, hope he hits the mouse buttons in the correct order?" Yeah, that makes an argument to dismiss the "Null hypothesis" of Test(sarcasm intended). The Null hypothesis of any manufacturing test is "someone failed to turn raw material into marketable product" As a Test Engineer - If I cannot find EVIDENCE to dis-prove that hypotesis we can sell the product (for a profit maybe) when I need to guess on user actions my controls on the process lower...and my product quality will decrease (Lowering my profit!)

    "Push the button, get a banana" that is the target of any user of an automated test that has a high level of reliabilty and consistancy.

    So, why is the CLI so poorly documented?