The main dialog (see Figure 4.1) contains a pull down menu, interface selection box, lock protection bits box, device action buttons, report (status) window, open file buttons, target device information box, serial number box, power DC status and check sum result boxes.
All device action buttons, power ON/OFF button and the check sum result box have their own status indicators. Each indicator can assume any of the following conditions:

Open

Open

Figure 4.1: Main Dialog Screen.

4.1 MCU Device Type

Target MCU device type can be selected from the pull down field of the Family, Group, and Name menus shown in Figure 4.2. The pull down fields contains a list of all devices in the selected category currently available.
When communication between the microcontroller and the programming adapter is initialized, the software will detect the target microcontroller automatically. The type of detected microcontroller is displayed in the field "Target:". This allows the software to warn the user if the connected microcontroller does not match the one specified during configuration.

Figure 4.2: The MCU type can be selected here.

4.2 Code File Management

The programmer provides several options to manage code files. These options allow the user to open a code file, append multiple code files, and save memory or read code data into a new code file. The "Open Code File" button, or the File→Open Code File option prompts for opening the target file that contains the code data, as shown in Figure 4.3. When the first file is selected using this option the code buffer is reset and the contents of this file are read into memory. If the selected target device does not have enough flash memory to fit the data contained in the code file, a warning message as shown in Figure 4.4 will appear.

Figure 4.3: Select the Code file you wish to program to the MCU.

Figure 4.4: Code size exceeds Flash size.

When a code file is opened and read successfully the code file name and full path will be displayed on the right side of the "Open Code File" button. Contents of the selected file can be viewed by selecting the View→Code File Data option. The code buffer can be appended with additional files using the “Append” button, or the File→Append Code File option. The behavior of this feature is the same as “Open Code File” except that the code buffer is not reset, but rather appended with new data every time a new file is added. Overwriting data from a previous code file is not allowed and will cause an error to be displayed.

The File→Save Code as... option saves the data currently contained within the code buffer into a single code file (useful for combining multiple code files). When the user selects this option the window in Figure 4.5 will appear, prompting for the name of the file to be created. The File→Save Memory as... option will save the code read from a target device into a code file similarly to the File→Save Code as... option. All of the aforementioned Code File options work with the three most popular code file formats. These formats are the Texas Instruments, the Motorola and the Intel file formats. The programmer will work with any of these formats and will easily convert one file format to another by using the File→Open Code File and File→Save Code as... options.

Figure 4.5: Save code file.

4.3 Flash Protection Bits or Option Bytes

Flash memory within the ARM series devices can be protected against unauthorized program or read access. The programmer software allows the user to program these bits by selecting the "Enable" check-box within the "Memory Protection" area in the top right corner of the main dialog screen (shown in Figure 4.1). When the "Enable" option is selected, then all protection bits will be programmed during the “Auto Program" procedure after code contents have been programmed and verified correctly. These bits can also be programmed manually by pressing the "Lock Device" button. When programming Flash Protection Bits it is necessary to power-cycle the target device to verify that these bits have been successfully committed (see Section 4.4).

The desired configuration of protection bits can be chosen in the Setup→Memory Protection dialog screen (shown in Figure 4.6). The user can select an address range to be protected (for no protection specify both values as 0), or modify individual register bits. Additional protection can be enabled by totally disabling debug access to the MCU. After debug access is disabled then JTAG can no longer be used to communicate with the target device. All these protection bits can either be chosen from the dialog screen, or taken from a code file.

Figure 4.6: Memory Protection.

Although some devices allow the user to reset these protection bits to factory settings using the "Clear Locked Device" procedure, not all devices support this feature. On a few devices protection bits cannot be re-programmed once committed. Therefore it is important to verify if the recovery procedure is supported on the target MCU by checking the relevant technical reference manual if you intend to program protection bits multiple times.
Some processor revisions are known to contain bugs that prevent memory protection bits from being committed (e.g. see LM3S3748 RevA0 errata). In some cases you can still disable debug access because the debug register commits successfully, consult MCU errata on the relevant vendor’s website regarding the revision you are using. When the programmer detects that protection bits have not been programmed successfully, but the user has requested to program debug bits, a popup message will ask if programming should proceed anyway (see Figure 4.7). Normally, the debug register is programmed last only if all other operations are successful.


Figure 4.7: The programmer will ask the user if they wish to program the debug register even if protection bits haven't been programmed successfully. This is useful in overcoming some processor bugs that prevent protection bits from being committed.

On other MCUs where the debug configuration is separate from flash erase and write protections, it is enough to enable the correct bits in the Setup→Memory Protection dialog screen to avoid errata issues.

4.4 Power Device from Adapter

The programming adapter is powered from the USB Port interface. A target device can be powered from the programming adapter with voltage range from 1.2 V to 4.0 V in 0.1 V steps selected in the voltage selector located in the “MCU Vcc" box (see Figure 4.8).

Figure 4.8: Power device.

The target device will be powered from the adapter if the check-box "Enable" is selected. By clicking the POWER ON/OFF button you can also turn the power on or off manually on the target device. The DC voltage on the target device is continuously monitored and displayed in the “MCU Vcc" box, even if the target device is powered from an external DC source. If power is supplied from the adapter, and the XStream-Iso or XStreamPro-Iso adapter is used, the current consumption is also displayed.
When the target device is powered from an external power supply then the check box "Enable" should not be selected. RESET button located on the right side on the POWER ON/OFF button (Figure 4.1) can generate a reset pulse to the target device. Pressing this button will reset the target device manually at any time.
When programming Flash Protection Bits or Option Bytes it is sometimes necessary dependent on the MCU to power-cycle the target device to verify that these bits have been successfully committed. The programmer will do this automatically when power is taken from the adapter. However, if power is taken from an external power source and the "Enable" check-box is disabled in the "MCU Vcc" area, a popup message will wait for the user to power-cycle the device before proceeding with verification. If a power-cycle is not possible because of the production setup, it is possible to skip this step and continue all programming until the end by disabling the “Verify Protection in Lock Device Procedure” checkbox in Setup→Memory Options dialog screen (Figure 4.9)

Figure 4.9: Check boxes will indicate the statue of each operation during programming.

4.5 Target Device Action Result

After any programming action is performed, a result icon will be displayed next to the button pressed indicating the result status. Some actions, like “Auto Program", perform many tasks and each part of the result is displayed in the test result icons (see Figure 4.10).

Figure 4.10: Check boxes will indicate the statue of each operation during programming.

4.6 Device Action Box

The Device Action box contains multiple buttons (see Figure 4.11), and several checkboxes with optional features. Each button allows a specific action to be executed. Software procedures related to each action allow you to fully execute the desired task, without the need to follow a specific sequence of actions. Nevertheless, every action requires the “Verify Access” step to succeed. This step starts by powering up the target device if “MCU Vcc” is enabled providing power from the adapter. If external power supply is used, it is enough that the sensed Vcc meets the minimum target requirements which are noted from device datasheets and stored in the software’s MCU database. If minimum voltage is supplied, communication with the target device is initiated via the debug interface, JTAG, cJTAG, or SWD. If the debug interface is disabled for any reason (i.e. debug register has been programmed to disable debug interface), the “Verify Access” step will fail and all procedures will stop. However, if communication initialization succeeds (which involves successfully reading the MCU device ID and configuring the internal oscillator to an acceptable frequency) a green check mark will appear next to “Verify Access” (see Figure 4.11).

Progress of all actions is displayed in the report window. If the particular action has been finished successfully, then a "done" or "OK" will appear on the right side of processed procedure (Figure 4.12). The “done” message denotes that the procedure is finished, however not verified. For example, to verify the “Erase Flash” step a “Blank Check” procedure should be issued. The “OK” message is returned if positive confirmation was received from the MCU. This is true for the “Write Flash” step; however, a proper “Verify Flash” procedure is strongly encouraged unless tight time constraints are necessary. A "failed" message will be displayed if an error was detected. An error will generally stop the process and terminate the sequence of any follow-up actions, with a few exceptions: (1) a full blank check fail, will start a partial blank check that can pass, and a (2) locked device can trigger an unlock attempt. Final status is also displayed in the Status window (see Figure 4.13) as Active (blue), Pass (green), or Fail (red). On the bottom of the programmer dialog screen the progress bar is displayed and the total run time is shown in the report window. Run time does not include the time when user interaction is required.

Figure 4.11: Actions that can be taken using the Programmer.

Figure 4.12: This text window shows text messages describing the actions being performed, and how long they take.

Figure 4.13: A summary of the entire programming procedure.

4.6.1 Auto Program

The "Auto Program" button is the most frequently used button when programming a target microcontroller device in a production process. The "Auto Program" function executes all macro procedures, specifically Erase, Blank Check, Program, Verify, and Lock plus some optional features. In greater detail, the "Auto Program" function executes the following procedures:

1. reload code file: when "Reload Code File" is selected read code file contents every time before programming (useful for debugging when the code file is frequently modified).

2. initialization (VERIFY ACCESS button): power on and communication initialization.

3. read retain data from the flash if specified in Setup->Memory Options (optional): because flash contents have to be erased for programming, this step involves reading and restoring “retain data” area.

4. read serialization information (Serial Number, Model, Group, Revision) (optional): if serialization is used, locations selected for Serial Number, Model, Group, Revision are read, and if not empty, the user has an option to selected old or new serialization. If the “Warn if Target Flash not empty on the SN location” box is unchecked in Setup->Serialization, any old serialization information is overwritten.

5. ERASE FLASH button (erase flash memory): flash area specified in Setup->Memory Options is erased. Some MCUs require a full erase is necessary. In general, at least a page has to be erased to write to that location.

6. BLANK CHECK button (erased memory blank check, unless “Enable Blank Check” box is unchecked): same area of flash that was selected to be erased in previous step is verified to be blank. This step is important because writing to flash that is not blank can damage the flash permanently.

7. WRITE FLASH button (flash programming): flash area specified in Setup->Memory Options is written with code file contents.

8. write retained data (optional): flash contents saved for reprogramming are now written.

9. verify retained data (optional): restored flash contents are verified.

10. WRITE SN / Model button (step 1, write new serialization data, optional): if serialization is used, new Serial Number, Model, Group, Revision data is read from serialization input file or auto generated to be programmed to target device.

11. WRITE SN / Model button (step 2, verify serialization data, optional): if serialization is used, programmed serialization data is verified.

12. VERIFY FLASH button (programmed flash verification): same area of flash that was selected to be written in flash programming step is verified to be programmed correctly. Based on options in Setup->Memory Options this can be “None”, “Fast” (PSA and CS) - default, “Standard” (PSA, CS and full readback).

13. Lock Device button (step 1, write and verify non-debug option bytes, optional): if memory protection is enabled in Main GUI, and in Setup->Memory Protection, option bytes not related to the main debug interface register are programmed and verified.

14. Lock Device button (step 2, write and verify debug option bytes, optional): if memory protection is enabled in Main GUI, and in Setup->Memory Protection, option bytes related to the main debug interface register are programmed and verified. This can irreversible lock the MCU.

Sample report window messages from the "Auto Program" procedure are shown in Figure 4.14 and Figure 4.15.
Status window (see Figure 4.13) has a counter that is useful in a production process. The total number of programmed devices can be entered in the Total edit line. The Balance line shows the number of devices that have not been programmed yet. The Balance counter is initialized to the value entered in the Total edit line and is decremented every time “Auto Program" is completed successfully. In the Gang case, the number is decremented by the total amount of devices programmed successfully. In the bottom box in the Status group is displayed the number of available serial numbers taken from a user specified serial numbers file.
Note: Balance counter works only with the "Auto Program" procedure.

4.6.2 Verify Access

This button allows the user to check that the FlashPro-ARM Programmer has access to the target device. In the GangPro-ARM case, a separate success checkmark will be indicated per device. The Gang programmer will proceed as long as at least one device is working properly; which is to say that if initial programming started with six (6) devices, it’s possible that only five (5) devices will initialize properly. In this case programming will only be attempted on the five (5) properly running devices.

4.6.3 Erase Flash

The "Erase Flash" function erases the selected flash memory segments, or mass (all) memory. If any option other than "Erase All Memory" is selected in the Memory Options Setup (see Chapter 6 for configuration details), then a message shown in Figure 4.16 will be displayed. This message clarifies which segment of flash memory is to be erased because typically a mass erase is recommended. This warning window can be turned off in Setup->Preferences.

Figure 4.16: This message clarifies which segment of flash memory will be erased.

4.6.4 Blank Check

The "Blank Check" function checks if flash memory of the target microcontroller is blank (all bytes contain the value 0xFF, or 0x00 depending on MCU family). This test performs two checks: (1) determine if the entire memory contents are clean, (2) check memory segments specified by the user (see setup in Memory Erase/Write Group). The following conditions can appear at the completion of this operation:

all memory is blank

all memory is not blank, but selected part of it is blank.

memory is not blank.

4.6.5 Write Flash

The "Write Flash" function writes contents from the code file to flash memory. If this button is pressed for a second time after the target device has already been programmed, then programming will fail because those flash segments are not empty. Erase and blank check flash segments you wish to program before pressing the "Write Flash" button (see Chapter 6 for configuration details).

4.6.6 Write SN/Model

When the "Write SN/Model" button is clicked, Serialization (see Chapter 8.2) information will be manually programmed to the target device. It is NOT recommended to use this button outside of the "Auto Program" procedure other than for testing purposes. Only the "Auto Program" procedure will decrement serial numbers from a serial numbers file (if specified) and log used serial numbers into the output file. Also, if you choose to select Check Sum Options (see Chapter 9), a check sum that includes the serial number will not be updated if you change the serial number using this button manually.

4.6.7 Verify Flash

The "Verify Flash" function compares the contents of flash memory with data from the code file. This function can use the standard memory verification method (byte by byte) or verify the calculated check sum of the code and check sum of the flash contents (see Chapter 6).
Note: During verification, either all memory or just the selected part of memory is verified, depending on settings specified in the Memory Erase/Write Address Range in the Setup->Memory Options dialog. See Chapter 6 for details.

4.6.8 Read/Copy

The "Read/Copy" function reads data from the target microcontroller (or six in the Gang programmer case) and displays it in the Flash Memory Data window (see Figure 4.17 and Figure 4.18). This window can also be opened by selecting the View→Flash Memory Data option. Flash memory data viewer, shown below displays the code address on the left side, data in hex format in the central column, the same data in ASCII format in the right column. Contents of the code viewer can be saved and converted to Texas Instruments txt file format by clicking on the “TI hex (*.txt)" button or to Intel hex format by clicking on the “INTEL (*.hex)” button. Output data will be shown in Notepad.
The address range to be displayed in the Flash Memory Data window can be specified in the Memory Options screen. See Chapter 6 Read group for details. When the "Copy" button is clicked, then contents of the read target device memory will be saved in the specified by user file name and opened as a current Code File. As a consequence of this action, programmer setup will be modified for the copy procedure. Serialization will be disabled and the "All Memory" option will be selected in the "Write/Erase/Verify Address Range". The message shown in Figure 4.19 will be displayed. When the button "OK" is pressed then the programmer is ready to program the target device.

4.7 Next Button

The "NEXT" button is a dynamically programmable device action button (use shortcut function key F5 to operate). At start-up the "Next" button is disabled (see Figure 4.20, left), but when any button from the Device Action group is pressed, the "Next" button will take on the name and feature of that button. For example, if "Auto Program" has been used then its name will be displayed on the "Next" button (see Figure 4.20, middle) and it will perform the same function as the "AUTO PROG." button. The "NEXT" button will retain this functionality until a different Device Action button is pressed. For example if the button, "READ / COPY", is clicked then from this moment on the button "NEXT" will take the name and function of the "Read Flash" button and so on (see Figure 4.20, right). The purpose of the "Next" button is to perform the same task repeatedly on a series of target MCUs during production.

Figure 4.20: The next button can take on multiple functions depending on which Device Action was used previously.