Generic DLL CLI: Getting Started

Problem

After installing the Generic DLL package from the website Downloads tab, how do I run my first adapter using the CLI?

Solution

  1. Go to Generic-FPA-DLLs\bin\Win32, and open FPAs-setup.ini, you will see contents similar to this listing an adapter to be specified on index 1:
    FPA-1 20204012 TYPE-ARM

  2. Change the serial number to specify your adapter. Specify the type to TYPE-ARM or TYPE-ARM-GP, etc. From Generic-FPA-TS.h found in Generic-FPA-DLLs\include the types are:
    "C2000" - FlashPro-2000
    "CC" - FlashPro-CC programming 8051
    "CC-GP" - GangPro-CC programming 8051
    "ARM" - FlashPro-ARM, FlashPro-MSP programming MSP432
    "ARM-GP" - GangPro-ARM, GangPro-CC programming CM3
    "MSP" - FlashPro-430, FlashPro-MSP programming MSP430
    "MSP-GP" - GangPro-430
    "M" - FlashPro-M
    "M-GP" - GangPro-M
    When using FlashPro-X or GangPro-X adapter, select from above list based on target MCU.

  3. If you have a newer installation of ARM/MSP430 etc. than is present in the Generic bin directory, copy the appropriate DLLs there; i.e. for ARM: FlashProARM-FPA1.dll and GangProARM-FPA1.dll, from the ARM install directory to Generic-FPA-DLLs\bin\Win32. The Generic DLL uses 32-bit DLLs (x86 installations).

  4. Open two cmd.exe consoles, go to Generic-FPA-DLLs\bin\Win32, and check your adapter connectivity using the following command:

    Above you can see adapter with SN: 20204012.  Copy that serial number to the FPAs-setup.ini file.
  5. In the same console used for the DISCOVER command start the server with the FPAs-setup.ini file and -b option (blocking calls).  This starts the server process that keeps track of up to 64 adapters. This process is persistent and should be kept running until everything is finished.

    Server process detected one adapter specified in FPAs-setup.ini file. The specified option -b will execute all requests as blocking.
  6. The server process can be started with the following options:
    Generic-CommandLine-Server.exe [Optional Settings] <setupfile or DISCOVER>
    Required Settings:
    <setupfile>: FPA assignments
    or keyword DISCOVER: run in discovery mode, print connected FPAs (up to 64) and exit. Use to dynamically create setupfile. Requires msp430fpa1.dll

    Optional Settings:
    -configtest : interpret configuration settings, touch log files (open for append), show errors, and quit.
    Incoming Connections:
    -p <pipename> : optional flag to specify named pipe for clients to connect to (default: \.\pipe\elprotronic).
    -b : client commands block until completion (no BUSY replies), meaning that only one command can be issued at a time. Required to set FPA index to 0 (all FPAs) on single client connection. Works well for one FPA, or broadcast style control of all FPAs with one client.

    Feedback to Clients:
    -f 3 (default) : client feedback very verbose, echo back commands as read by server, info text, error text, return values and busy status.
    -f 2 : client feedback verbose, print error text, return values and busy status.
    -f 1 : client feedback low, only print return values and busy status.
    -f 0 : no client feedback, clients have to request function return with 'LastStatus <fpa>' command.
    Server Output:
    -v 3 (default) : server very verbose, echo client commands, info text, print initialization status, error text, and return values.
    -v 2 : server verbose mode, print initialization status, error text, and return values.
    -v 1 : server low verbose mode, only print error text.
    -v 0 : server silent mode, no output (malformed configuration options will still print errors at start-up).
    -of <filename> : send server non-error output to file with path <filename>.
    -ofr <filename> : send server error output to file with path <filename>. Errors during initialization will always go to stderr.
    -of_fpa <i> <filename>: send server non-error output only for fpa index <i> to file with path <filename>.
    -ofr_fpa <i> <filename>: send server error output only for fpa index <i> to file with path <filename>. Errors during initialization will always go to stderr.
    -ofq : stop server if write to any log file fails for any reason. Logging error will be dumped to -ofr <filename>, or if that fails then to stderr before exit. The server will exit regardless of this setting if it fails to open the provided files during initialization.
    Example usage for development:
    Generic-CommandLine-Server.exe -p \.\pipe\mypipe -b FPAs-setup.ini Simple setup that will read FPAs-setup.ini file for list of FPAs, and will accept connection on mypipe. Feedback from server and to clients will be very verbose making it easy to see what is going on. Server will block on client commands, and reply with function return whenever it completes (no BUSY response).
    Example usage for production with local logging:
    Generic-CommandLine-Server.exe -p \.\pipe\mypipe -of FPAserver.log -oq -f 1 -v 2 FPAs-setup.ini
    This setup logs minimal amount of information to FPAserver.log file. If logging fails the server will stop.
    Standalone process will accept up to 'n' connections, where n is the number of correctly initialized FPAs. This process will persist until killed or client issues F_CloseInstances command.

    Use demo client or your own application to connect to this process and type commands using command line. One connection can control all or one FPA.

  7. In another cmd.exe console, go to same directory and run the client:

  8. Example sequence of loading configuration file, loading code file, and running auto program command. In this example the client is calling command in script mode. First screenshot shows client command and second screenshot shows the corresponding server output. The third screenshot is shows how to get GUI-like text output using the client.

  9. Optionally, the user might want to read individual bytes, etc.  A list of all available commands are available in corresponding manuals, like the ARM DLL manual. The Generic DLL supports all DLL commands from all sub-DLLs like ARM, M, C2000, MSP430 etc.  Sequential commands like reading and writing bytes bytes require the device to be initialized explicitly using Open_Target_Device (to turn on target and comm.), and de-initialized using Close_Target_Device (close comm. and power down).