Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents

...

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:

  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.

...


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.