4. Main Graphical User Interface
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:
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: