Versions Compared

Key

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

...


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. Image Removed

...

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

...


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

...

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.