...
Anchor |
---|
| _Toc452148535 |
---|
| _Toc452148535 |
---|
|
Anchor |
---|
| _Toc450742564 |
---|
| _Toc450742564 |
---|
|
Figure 4.2: The MCU type can be selected here. Anchor |
---|
| _Toc452148470 |
---|
| _Toc452148470 |
---|
|
4.2 Code File Management
...
Anchor |
---|
| _Toc452148538 |
---|
| _Toc452148538 |
---|
|
Anchor |
---|
| _Toc450742567 |
---|
| _Toc450742567 |
---|
|
Figure 4.5: Save code file. Anchor |
---|
| _Toc452148471 |
---|
| _Toc452148471 |
---|
|
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).
...
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.
Anchor |
---|
| _Toc452148539 |
---|
| _Toc452148539 |
---|
|
Anchor |
---|
| _Toc450742568 |
---|
| _Toc450742568 |
---|
|
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.
...
Anchor |
---|
| _Toc452148543 |
---|
| _Toc452148543 |
---|
|
Anchor |
---|
| _Toc450742572 |
---|
| _Toc450742572 |
---|
|
Figure 4.10: Check boxes will indicate the statue of each operation during programming. Anchor |
---|
| _Toc452148474 |
---|
| _Toc452148474 |
---|
|
4.6 Device Action Box
...
Anchor |
---|
| _Toc452148544 |
---|
| _Toc452148544 |
---|
|
Anchor |
---|
| _Toc450742573 |
---|
| _Toc450742573 |
---|
|
Figure 4.11: Actions that can be taken using the Programmer. Anchor |
---|
| _Toc452148545 |
---|
| _Toc452148545 |
---|
|
Anchor |
---|
| _Toc450742574 |
---|
| _Toc450742574 |
---|
|
Figure 4.12: This text window shows text messages describing the actions being performed, and how long they take....
Anchor |
---|
| _Toc452148546 |
---|
| _Toc452148546 |
---|
|
Anchor |
---|
| _Toc450742575 |
---|
| _Toc450742575 |
---|
|
Figure 4.13: A summary of the entire programming procedure. Anchor |
---|
| _Toc452148475 |
---|
| _Toc452148475 |
---|
|
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:
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).
initialization (VERIFY ACCESS button): power on and communication initialization.
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.
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.
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.
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.
WRITE FLASH button (flash programming): flash area specified in Setup->Memory Options is written with code file contents.
write retained data (optional): flash contents saved for reprogramming are now written.
verify retained data (optional): restored flash contents are verified.
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.
WRITE SN / Model button (step 2, verify serialization data, optional): if serialization is used, programmed serialization data is verified.
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).
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.
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.
...
This button allows the user to check that the FlashPro-ARM M Programmer has access to the target device. In the GangPro-ARM M 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.
...
Anchor |
---|
| _Toc450742576 |
---|
| _Toc450742576 |
---|
|
Anchor |
---|
| _Toc452148547 |
---|
| _Toc452148547 |
---|
|
Figure 4.16: This message clarifies which segment of flash memory will be erased. Anchor |
---|
| _Toc452148478 |
---|
| _Toc452148478 |
---|
|
4.6.4 Blank Check
...
Anchor |
---|
| _Toc452148550 |
---|
| _Toc452148550 |
---|
|
Anchor |
---|
| _Toc450742579 |
---|
| _Toc450742579 |
---|
|
Figure 4.20: The next button can take on multiple functions depending on which Device Action was used previously.