Flash An 5061
Flash An 5061
Application Note
1. Introduction
This document explains how to add support for
additional flash devices on the Flash Programmer for Contents
CodeWarrior™ Development Studio for QorIQ LS 1. Introduction ............................................................... 1
series - ARM V7 ISA by using the Flash Tool Kit. To 2. Preliminary Background ........................................... 1
add support for a new flash device, you need to write a 3. Flash Tool Kit (FTK) Overview ................................ 2
4. Creating Flash Device XML Configuration File ....... 2
new flash programming algorithm and create some 5. Creating New Target Task ...................................... 12
supporting files. 6. Creating External Flash Algorithm ......................... 23
7. Creating New Flash Utility ..................................... 37
This document explains: 8. Troubleshooting Flash Programmer ........................ 45
• Creating a flash device XML configuration file
• Creating a new target task
• Creating an external flash algorithm
• Creating a new flash utility
• Troubleshooting flash programmer
2. Preliminary Background
Before you program or erase any flash device, you must
ensure that the CPU can access it. For example, you
might need a different debug setup that requires
modifications to the debugger configuration file.
Consider the following before you begin:
• Read the flash device ID to verify correct
© Freescale Semiconductor, Inc., 2014. All rights reserved.
Flash Tool Kit (FTK) Overview
To add a new device to the CodeWarrior Flash Programmer, you must add a new file that describes the
device.
<device-file>
<device>
<content>
<name>NameOfFlashDevice</name>
<manufacturerid>MfgID</manufacturerid>
<chiperase>TRUE or FALSE</chiperase>
<sectors>
<sectorcount>NumberOfSectors</sectorcount>
<sectorsize>SectorSize</sectorsize>
.
.
<sectorcount>NumberOfSectors</sectorcount>
<sectorsize>SectorSize</sectorsize>
Adding Device(s) to the CodeWarrior™ Flash Programmer for ARM™ V7
2 Freescale Semiconductor
Creating Flash Device XML Configuration File
</sectors>
<organization>
<name>Capacity/BusWidth/NumberOfDevices</name>
<id>DeviceID_ForBusWidth</id>
<algorithm>FlashAlgorithmForVariant</algorithm>
<utility>FlashUtilityForVariant</utility>
</organization>
.
.
<organization>
<name>Capacity/BusWidth/NumberOfDevices</name>
<id>DeviceID_ForBusWidth</id>
<algorithm>FlashAlgorithmForVariant</algorithm>
<utility>FlashUtilityForVariant</utility>
</organization>
</content>
</device>
</device-file>
<manufacturerid>MfgID</manufacturerid>
<id>DeviceID_ForBusWidth</id>
<chiperase>TRUE or FALSE</chiperase>
<sectorcount>NumberOfSectors</sectorcount>
<sectorsize>SectorSize</sectorsize>
For example, for a device that has eight (8) sectors of 0x2000 bytes, each followed by 30 sectors of
0x10000 bytes and another eight (8) sectors of 0x2000.
<sectors>
<sectorcount>8</sectorcount>
<sectorsize>2000</sectorsize>
<sectorcount>30</sectorcount>
<sectorsize>10000</sectorsize>
<sectorcount>8</sectorcount>
<sectorsize>2000</sectorsize>
</sectors>
Older flash devices can have sectors of different sizes. If you use such an older device, ensure that each
sector in the configuration file is of the correct size.
Device size is the size of the device. It can be expressed as KB or MB using K and M suffixes.
Examples: 128K, 1M.
Many flash devices can be set to use either 8-data bits or 16-data bits depending on the status of a
configuration pin (typically named BYTE#) on each device. The <organization> field uses this part of
the flash definition, as described in the next paragraph. Your target uses only one configuration so you
need to support only that configuration. Expanding your new definition to include the other
configurations for this device, however, is a good design practice.
Your target may use one, two, or four devices at the same base address to support an 8-bit, 16-bit, 32-bit,
or 64-bit data bus.
For example, two 8-bit flash devices side by side support a 16-bit data bus, and four 16-bit devices
support a 64-bit data bus. The <organization> field summarizes each possible combination of device
capacity, bus width, and number of devices used.
For example, 4Mx16x1 means 4MegaHalfwords by 16 data bits per device by 1 flash device, resulting in
a total of 4M 16-bit half words. Similarly, 1Mx8x4 means 1MegaByte by 8 data bits per device by 4 flash
devices, resulting in 1M 32-bit words and a 32-bit data bus presented to the processor.
<organization>
<name>Capacity*BusWidth*NumberOfDevices</name>
</organization>
For example, see how the latter was built as an extension of the former. Note also how the part
number of your device may be only a revision letter different from a defined part.
<algorithm>FlashAlgorithmForVariant</algorithm>
FlashAlgorithmForVariant is the algorithm name without full path (just the .elf file name).
{CodeWarrior}\ARMv7\bin\plugins\support\Flash_Programmer\ARM_EABI
Create an algorithm file name by combining the fields: manufacturer, data bits per device, and number
of flash devices.
If the device does not have built-in algorithm support, you can create your own algorithm and use it with
the CodeWarrior Flash Programmer. For more information, see Creating External Flash Algorithm
section.
If the flash memory device supports two types of connections, 8-bit or byte connection and 16-bit or
word connection, then use an alternative algorithm.
In all other cases or for AMD flash devices that do not support two types of connections, use the
common Spansion algorithm.
Flash command register addresses are the main difference between common and alternative algorithms.
For example, command addresses for the flash algorithm are: 0xaaa, 0x554, 0xaaa. If these command
addresses are not working, refer to device’s datasheet.
Table 2 lists algorithms, device compatibility, and other information for flash manufacturers.
<ontargetverify>TRUE or FALSE</ontargetverify>
verify operation is made on the host itself), which has a significant impact on the run time. To combine
both the operations, perform the following steps:
1. Add <verifyafterprogram> tag in all the XML Flash Programmable devices.
2. The Verify after program checkbox appears in the Add Program/Verify Action dialog. It
indicates that a verify operation is combined with the program operation for the file. Ensure to
select Verify after program checkbox.
Figure 1. Add Program/Verify Action dialog
<utility>FlashUtilityForVariant</utility>
Adding Device(s) to the CodeWarrior™ Flash Programmer for ARM™ V7
10 Freescale Semiconductor
Creating Flash Device XML Configuration File
<product>
<file>
<name>FP_ARM</name>
<version>1.0</version>
<path>Product/FPDevProductData.xml</path>
</file>
</product>
<device>
<file>
<name>JS28F00AM29EWHA</name>
<version>0</version>
<path>FP/JS28F00AM29EWHA.xml</path>
</file>
6. Add the new file anywhere in <device> tag. For this example, it will be added at the
beginning.
<product>
<file>
<name>FP_ARM</name>
<version>1.0</version>
<path>Product/FPDevProductData.xml</path>
</file>
</product>
<device>
<file>
<name>NewFlashDevice</name>
<version>0</version>
<path>FP/NewFlashDevice.xml</path>
</file>
<file>
<name>JS28F00AM29EWHA</name>
<version>0</version>
<path>FP/JS28F00AM29EWHA.xml</path>
</file>
NOTE It is highly recommended to back up the manifest file before updating it. If an error
occurs, the CodeWarrior software may not be able to parse some devices.
Next, create a Flash Programmer task representing the starting point for any flash operation. This defines
the flash device to be used and the memory buffer, and creates some default actions.
2. The Create New Target Task wizard appears (Figure 4). Specify information in the following
fields:
Task Name: Name of the target task.
Task Group: Group where the task is to be created. If only Root exists this option is disabled.
Run Configuration: Each task must be associated with an existing Launch Configuration or
Active Debug Context. This association is required to be able to make a connection to the
target when doing operations over the flash. Active Debug Context means a connection is
already established and only the task needs to be executed. Use Active Debug Context for
generic tasks or when it is not known which Launch Configurations are available.
Task Type: Type of task created. Select Flash Programmer for ARM.
A pop-up window displays indicating that the device has been added.
5. Click Done. The selected devices are added in the Flash Devices table.
All these values must be correct for the board where the flash device is located. Figure 7 shows the
default values for board LS1021 QDS S25FL128S QSPI flash device. All fields that must be filled are
highlighted with red.
Figure 7. Populate Default Values
All these operations can be selected using Add Action button. In the below steps, this step is not
mentioned to avoid the repetition.
You can associate the above actions with the target task using the buttons in the Flash Programmer
Actions section in the Flash Programmer Task editor. You can arrange the order of the actions using
the Move Up/Move Down buttons.
The Add Erase Action button enables you to erase a selected sector from the flash device and the Add
Blank Check Action button checks the erased sectors to verify if they have been fully erased.
7. Click Done to close the Add Erase/Blank Check Action dialog. The added erase /blank check
actions appear in the Flash Programmer Actions table (Figure 9).
5. Define how the file should be read by selecting appropriate option from the File Type drop-down
list. The following options are available:
• Auto: The Flash Programmer detects files of type Elf and Srec
• Elf: Elf executable file
• Srec: Motorola .s19 file format
• Binary: The file is read in binary format, no content interpretation is done
6. Select the Restrict to Addresses in this Range checkbox to define a range for flash accesses.
Any program/verify action performed outside this range is ignored. You can specify the range in
the Start and End text boxes, respectively.
7. Select the Apply Address Offset checkbox to apply an offset to the image to be written to the
flash device. You can specify the offset in the Address text box. This value is added to the
(computed) start address of the file.
The start address is zero for binary files or read from the file header. In case you want to use a
binary file and the flash is not mapped to zero, then enable the offset and set the value to the base
address of the flash.
The settings are displayed in Figure 10.
8. Click Add Program Action to add a program action for the flash device.
9. Click Add Verify Action to verify an action for the flash device.
10. Click Done to close the Add Program/Verify Action dialog.
Figure 10. Add Program/Verify Action Dialog
The added program/verify actions appear in the Flash Programmer Actions table as in the Figure 11.
The task is now complete and should be saved using Ctrl + S or Save icon from toolbar.
To create the new algorithm for flash programming, make all changes to the algorithm.c (flash
device algorithm implementation).
• Flash Algo Release: To create flash algorithm applet, the CodeWarrior Flash Programmer uses the
ELF executable file, created in Flash Algo Release. This build target shares the flash device
algorithm with the Flash Algo Development build target; it differs, however, because it cannot be
debugged or tested (Figure 14).
Figure 14. Flash Tool Kit Targets
The CodeWarrior Flash Programmer uses an exchange zone in target memory to communicate with the
flash applet. The Flash Programmer Target Configuration specifies the Target Memory Buffer; the
exchange zone is at the start of this buffer, as shown in Figure 15.
Parameter_block_t Structure
typedef struct pb
{
/*
* What function to perform.
*/
unsigned long function;
/*
* Where are we going to operate.
*/
pointer_t base_addr;
/*
* Number of items.
*/
unsigned long num_items;
/*
* Result of the operation that was executed.
*/
retval_t result_status;
/*
* Items to be used by the algorithm (data to be written, address of the sectors for
erase / blankcheck)
*/
pointer_t items;
/*
* Used internally only.
*/
unsigned long is_timebase_enabled;
/*
* Padding.
*/
unsigned long padding[3];
/*
* Base address for memory mapped registers.
*/
unsigned long ccsrbar;
/*
* Core Type - used for handle between different processor FP controller structs.
*/
unsigned long core_type;
/*
* Controller offset.
*/
unsigned long controller_offset;
/*
* Controller type.
*/
unsigned long controller_type;
/*
* Padding.
*/
unsigned long padding1[37];
/*
* Number of additional parameters sent by FP Plugin.
*/
unsigned long additionalParameterNum;
/*
* First additional parameter
*/
unsigned long additionalParameterStart;
/*
* Padding for other additional parameters.
*/
unsigned long padding2[7];
} parameter_block_t;
Listing 4 definitions:
• function: Command to be executed from the CodeWarrior Flash Programmer.
• base_addr: Start address of the flash memory.
• num_items: Number of items to be transferred from the CodeWarrior Flash Programmer to the
flash programming applet.
• result_status: Status of the command; through this field, the flash programming applet
notifies the CodeWarrior Flash Programmer about the status of the command being executed.
Some values for result_status are defined in generic.h; however, the user can define
more, if needed.
• items: Start address of the data to be transferred from the CodeWarrior Flash Programmer to the
flash programming applet.
• is_timebase_enabled: A time-out mechanism can be implemented in the algorithm if
timebase is enabled.
• padding[3]: Used only for internal purposes.
• ccsrbar: Base address for memory mapped registers.
• core_type: Used for handling different processor FP controller structures.
• controller_offset: controller offset address
• controller_type: Controller type – not used for LS1 algorithms.
• padding1: Used only for internal purposes.
• additionalParamenterNum: Number of additional parameters sent by FP plugin.
• additionalParamterStart: Start address for additional parameters.
• padding2: Padding for additional parameters.
NOTE items and base_addr are of type pointer_t, which is a union that can
accommodate different types (such as char*, short*). This arrangement makes the
algorithm scalable, so it can be used for 8-bit, 16-bit, or 32-bit flash.
NOTE In case of custom hardware design, the debugger configuration file and the memory
mapping file must be written. Also, the memory initialization file for the flash device
should be checked before trying to create the new flash programming algorithm.
7. Modify the algorithm.c file:
The flash algorithm functionality file, algorithm.c, should be modified and filled with the
correct programming commands, as recommended by the flash device manufacturer.
8. Modify ID function in the algorithm.c file. It is mandatory to implement this function. The
CodeWarrior Flash Programmer uses the getting chip ID command right after the flash algorithm
is loaded to the memory buffer to check if the applet runs.
9. There is a corresponding function inside algorithm.c for every possible flash operation.
NOTE See the flash device manufacturer for the flash device memory organization. See
hardware description for the flash device addressing.
During new algorithm creation and testing, use the Flash Algo Development build target of the
Flash Development Kit. Compile the Flash Algo Development target with the algorithm.c
file, which is modified for the flash programming procedures. Compilation will result in creation
of a new flash_alg_debug.elf file.
11. Compile Flash Algo Release target:
When the flash programming algorithm for the new flash device works correctly, compile the
Flash Algo Release target. The output of the Flash Algo Release target —
flash_alg_release.elf — must be copied to the following folder:
{CodeWarior}\ARMv7\bin\plugins\support\Flash_Programmer\ARM_EABI
12. Add a new flash device to the flash programmer:
See Creating Flash Device XML Configuration File section for information on adding a new
flash device.
13. Create a new default target task:
See Creating New Target Task section for information on creating a new default target task.
14. Set flash device configuration in flash programmer:
Restart the Eclipse IDE so that the Eclipse IDE can use the new data from the updated
manifest file.
Select Window > Show View > Other… > Debug > Target Tasks from the menu bar to
open the Target Tasks view.
Right-click the Tasks table and select Import from the context menu (Figure 16).
Alternatively, click the icon on the Target Tasks view toolbar to import a task. The
Open dialog box appears.
Browse to the location of the task that you want to import, select the required task, and
click Open. The imported task gets added to the Tasks table.
Make a new Download Run Configuration (Right-click the project, select Debug As ->
Debug Configurations) specific for your board
o Select the project – Flash Tool Kit Template and the debug application
flash_alg_debug.elf
o Make a new connection – select the Initialization file, the System and Connection
type (usb, etap, gtap).
Check the Initialize target check box to select the Initialize target script for core0 from
the system list. Right-click the imported task and select Change Run Configuration
(Figure 17).
The Run Configuration dialog appears. Select the Run Configuration from the drop-
down list and click OK.
Double-click the task to open the task in the editor area.
Check if the flash device used is the newly introduced. As an example, the device is
named as NewFlashDevice (Figure 18).
Figure 18. Flash Task Editor
Save the task by pressing Ctrl + S or choosing Save button from toolbar.
Select Window > Preferences from the IDE menu bar. The Preferences dialog box
appears.
Select C/C++ > Debug > CodeWarrior Debugger and check the Show verbose output in
Target Tasks check box in the CodeWarrior Debugger panel.
Right-click the task and select Execute (Figure 20).
The Flash Programmer Console appears in the Console view and the task log gets
printed there.
Check for the algorithm used in console log. The section from Listing 5 should be
present.
Listing 5. Algorithm used for Erase operation
.
cmdwin::fl::erase all
Beginning Operation ...
-------------------------
log: Using Algorithm: flash_alg_debug.elf
.
.
Check in the log if the task is successful. The lines from Listing 6 should be present.
Listing 6. Part of Erase and Blank Check actions log
.
.
Erasing ............................
Reading erase return status
Erase Command Succeeded
Blank Checking ............
Reading blank check return status
Blank Check Succeeded
Adding Device(s) to the CodeWarrior™ Flash Programmer for ARM™ V7
34 Freescale Semiconductor
Creating External Flash Algorithm
NOTE: In case the flash device cannot be erased, check if you are using the correct target task,
and if the hardware connection is set up correctly.
Figure 22 definitions:
o Restrict to Addresses in this Range: Specifies the address range of the flash device
o Apply Address Offset: Specifies the start address, where the test data is
programmed in the flash; it should be the flash device start address.
Click Update Program Action.
Repeat steps d), e), and f) for Verify action.
Execute the task.
Check the Console view for the algorithms used in execution of the task, as shown in
Listing 7.
log:
Verify Command Succeeded
If all program/verify actions pass correctly, you have completed creation of a new flash
programming algorithm. The new flash device can be programmed with the CodeWarrior
Flash Programmer without any limitation.
To create a new utility for flash programming, make changes only to the utility.c file.
On the flash utility side, the commands from the CodeWarrior Flash Programmer go through the
parameterBlockType structure, and are mapped in the memory, from the beginning of the memory
buffer.
All commands from the CodeWarrior Flash Programmer are already encoded in utility_main.c
file. This file can be used for the new flash programming algorithm without any modification. After
loading the utility applet to the target board, the CodeWarrior Flash Programmer writes all parameters
right in the data structure located at the beginning of the memory buffer.
/*
* What function to perform
*/
unsigned long function;
/*
* Status of the operation
*/
unsigned long result_status;
/*
* Start address of the operation
*/
pointer_type start_address;
/*
* End address of the operation
*/
pointer_type end_address;
/*
* Total number of blank check errors found
*/
unsigned long numBlankCheckErrors;
/*
* Number of mismatches recorded
*/
unsigned long numRecordedBlankCheckErrors;
/*
* Address of the array of mismatches
*/
mismatchErrorType* mismatches;
/*
* Input and output checksum value
*/
unsigned long checksumValue;
/*
* Base address of the flash
Adding Device(s) to the CodeWarrior™ Flash Programmer for ARM™ V7
40 Freescale Semiconductor
Creating New Flash Utility
*/
unsigned long baseAddress;
/*
* Base address for memory mapped registers
*/
unsigned long ccsrbar;
/*
* Core Type - used for handle between different processor FP controller structs
*/
unsigned long core_type;
/*
* Controller Offset
*/
unsigned long controller_offset;
/*
* Controller Type
*/
unsigned long controller_type;
/*
* Number of additional parameters sent by FP Plugin
*/
unsigned long additionalParameterNum;
/*
* First additional parameter
*/
unsigned long additionalParameterStart;
/*
* Padding for other additional parameters
*/
unsigned long padding[7];
} parameterBlockType;
Listing 8 definitions:
magicNumber: Indicates a number written at the beginning of the flash utility parameter block.
The CodeWarrior Flash Programmer reads the first location from the memory buffer upon
downloading the utility. The expected value is 0xBCC5BCC5.
function: Specifies the command to be executed. It can be blank check or checksum.
result_status: Contains the operation result. It can be success, fail, or unknown command.
start_address: Specifies the start address for the requested command.
end_address: Specifies the end address for the requested command.
Adding Device(s) to the CodeWarrior™ Flash Programmer for ARM™ V7
Freescale Semiconductor 41
Creating New Flash Utility
numBlankCheckErrors: Stores the number of errors found during the blank check operation.
numRecordedBlankCheckErrors: Indicates the number of errors that have been recorded
during blank check. Up to 12 errors are recorded.
mismatches: Indicates a pointer to the mismatchErrorType structure defined in Listing 9.
It contains all errors recorded.
checksumValue: Specifies the checksum computed.
baseAddress: Specifies the base address of the flash.
ccsrbar: Specifies is the base address for memory mapped registers.
core_type: Helps to handle between different processor Flash Programmer controller structures.
controller_offset: Indicates the controller offset.
controller_type: Gives the controller type.
additionalParameterNum: Indicates the number of additional parameters sent by Flash
Programmer Plugin.
additionalParameterStart: Specifies the first additional parameter.
padding[7]: Is reserved for other additional parameters.
Listing 9. mismatchErrorType Structure Details
Listing 9 definitions:
address: Represents a structure of pointer_type defined in Listing 10. It contains the
address where an error has been found.
expected: Indicates the value expected to be found in flash memory.
actual: Indicates the value actually found in flash memory.
Listing 10. pointer_type Structure Details
The pointer_type is a somewhat generic pointer. We can use this pointer to get any data type—
unsigned char, short, long, long long, or void.
BlankCheck
The BlankCheck command is called by the flash programmer to blank check a memory range. For the
BlankCheck command, the CodeWarrior Flash Programmer:
Loads the flash utility on the target board
Sets the BlankCheck command as shown in the function field of Listing 8
Sets the start_address and end_address parameters as shown in the function field of
Listing 8
Runs the flash utility applet
Waits until flash utility stops execution
Checks the status of the command being executed as shown in result_status from Listing 8
Reads the number of errors and records the errors and their location if the status reports an error, as
shown in Listing 8
Checksum
The Checksum command is called by the flash programmer to blank check a memory range. For the
Checksum command, the CodeWarrior Flash Programmer:
Loads the flash utility on the target board
Sets the Checksum command as shown in the function field of Listing 8
Sets the start_address and end_address parameters as shown in the function field of
Listing 8
Runs the flash utility applet
Waits until flash utility stops execution
Checks the status of the command being executed as shown in result_status from Listing 8
Reads the checksum result if status is success, as shown in Listing 8
page appears.
Click Browse to choose the parent folder where you have copied the
FlashUtilityTemplate folder, select the folder, and click OK. The Projects list
gets populated with the projects available in the FlashUtilityTemplate folder.
Clear the check boxes next to the projects that you do not want to import and click
Finish. The imported project is displayed in the CodeWarrior Projects view in the
C/C++ perspective, as shown in Figure 23.
Ensure that the Flash Utility Development build target is selected.
3. Select RunDebug Configurations. The Debug Configurations dialog appears.
4. Expand the CodeWarrior Download tree node and select the desired launch configuration. If
one is not available, create one for your target processor.
5. Specify required target initialization and memory configuration files for the connected hardware
in the Target initialization file and Memory Configuration File text boxes. For supported
Freescale Evaluation Boards, you can use the debugger config files (*.tcl), and the debugger
mem files (*.mem) available with the CodeWarrior Development Studio. Check the folder:
{CodeWarrior}\ ARMv7\ARM_Support\Configuration_Files.
6. Modify executeBlankCheck function from utility_impl.c file. The function must
read the command options, perform the blank check and put the results in parameter block.
7. Modify executeCheckSum function from utility_impl.c file. The function must read
the command options, perform the checksum, and put the results back in parameter block.
8. Compile Flash Utility Development target. While creating and testing a new utility, use the Flash
Utility Development build target of the Flash Utility Template project. Compilation will result in
creation of a new flash_utility_debug.elf file.
9. Flash utility unit testing:
To test a flash utility algorithm, define custom flash device parameters in
utility_main.c. You can select the operation you want to perform and the address
in flash to which the operation will be applied.
Load the FlashUtilityTemplateDebug.elf file and run it on a target board.
Check the tests results.
10. Compile Flash Utility Release target. Copy the resulted file in the following folder:
{CodeWarior}\ARMv7\bin\plugins\support\Flash_Programmer\ARM_EABI
11. Use the new Flash Utility in the device description XML file. Run a Flash Programmer with the
new device/utility as described for the flash algorithm in Create New Flash Programming
Algorithm.
This topic explains how to configure your target flash devices to display their manufacturer and device
ID codes. If the devices can display this information, then basic reads and writes to the devices are
functioning correctly. This means that you are unable to program your flash due to either:
• The flash device configuration file
• The flash-programming algorithm
8.1. Theory
Current flash devices use a common method for preventing unintentional programming. A specific
sequence of write cycles must precede each flash programming write cycle, to enable programming of
one byte (8 bits) or word (16 bits). These preceding write cycles walk through an internal-state machine
that enables the flash for one device-programming write cycle. This write-enabling process is necessary
for each flash address to be programmed.
You can use the same method to configure a flash device to display its manufacturer and device ID
codes:
• The manufacturer ID code is the same for all devices from each manufacturer. Common codes are
0x01 for AMD, 0x1F for Atmel, and 0x89 for Intel.
• Device ID code is unique for each device; each device’s data sheet specifies its ID code.
Reading these ID codes requires successful write and read cycles to each flash device. This indicates that
the flash-programming problems exist in the CodeWarrior Flash Programmer rather than in the target
hardware. Similarly, inability to read these ID codes indicates a low-level problem with reading/writing
target flash. You must resolve such hardware problems for the flash programmer to work.
8.2. Practice
The explanation of this document involves using the CodeWarrior debugger and its Command Line
panel to write to and to read from target flash. Before you begin, you must be running a debug session to
the target.
The process uses the CodeWarrior commands, change, which writes to memory, and display, which
reads from memory. The general formats are:
change p:<address><value><bus-width>
display p:<start_address>..<end_address><bus-width>
Adding Device(s) to the CodeWarrior™ Flash Programmer for ARM™ V7
Freescale Semiconductor 45
Troubleshooting Flash Programmer
where:
• <address>, <start_address>, and <end_address> are address values that comply
with the CodeWarrior default radix, or with an explicitly defined radix.
• <value> is a data value that complies with the CodeWarrior default radix, or with an explicitly
defined radix.
• <bus_width> is 8bit, 16bit, 32bit, or 64bit.
These commands are used to push flash commands to the devices on your target and then to read the
data that the flash presents. All flash devices use a flash-command state machine to process commands,
such as ReadDevice ID, Erase Sector, and Program. See the data sheet for details of the device command
sequences.
This section presents common command sets for reading manufacturer and device IDs. To use any of
these examples, you must change the strings %%% to the high-order starting address of the flash on your
target. For example, if the flash base address is 0xffe00000, your replacement string for %%% is ffe.
The data values in these examples must remain as listed.
If the manufacturer of your target flash device is not AMD, Atmel, or Intel, then compare the command
sequences of your devices with the command sequences of the devices manufactured by AMD, Atmel,
and Intel. Most likely, your device uses the command sequence of one of these device manufacturers.
Fujitsu flash devices, for example, use the same commands as AMD devices. Sharp flash devices use the
same commands as Intel devices. And even if your flash device does not use exactly the AMD, Atmel,
or Intel command sequence, the command sequence should be nearly similar. You can, therefore, easily
adapt the command sequences of other device manufacturers.
NOTE You can also troubleshoot your flash device without the information listed above.
However, that would increase your efforts. The instructions below are consistent with
you having all this information.
8.5. Procedure
Perform these steps:
1. Start a CodeWarrior debugging session for your target.
2. Identify the appropriate command sequence for your device using Table 9.
If your manufacturer is Fujitsu, use the AMD listing for your arrangement.
If your manufacturer is Sharp, use the Intel listing for your arrangement.
Otherwise, find the closest match for your device arrangement, so that you can modify the
command sequence explained in Step 3.
3. Substitute the high order address string with %%% in the code of the selected listing and perform
either of the following:
Enter the listing commands one after another, in the Debugger Shell view, or
Copy the commands, paste them into a .tcl text file, then use a source command in the
Debugger Shell view to invoke the new script.
4. In the output of the display command, look for the ID codes of your flash device. The device’s
data sheet specifies these code values.
If the output includes the ID codes, you have confirmed that flash device basic reads and
writes function properly. This means that any programming problem lies with the
CodeWarrior software, so you should report the matter to Freescale Technical Support:
Adding Device(s) to the CodeWarrior™ Flash Programmer for ARM™ V7
48 Freescale Semiconductor
Troubleshooting Flash Programmer
www.freescale.com/support.
If the output does not include the ID codes, you have confirmed a low-level problem with
reading from or writing to your flash devices. You must solve this problem locally for the
CodeWarrior Flash Programmer to work.
8.7. Examples
Following is an example of flash interrogation that is common for some target boards that use Spansion
or AMD devices.
The commands have been executed on a LS1021A QDS board. For Spansion, one device with 16-bit
access instructs the use of Listing 17.
NOTE The comment lines in Listing 32 are for clarification. The CodeWarrior source command
discards comment lines, so you will not see such comments in your Debugger Shell
view.
Listing 32. Example One Results
The results of display line show the manufacturer ID code 0x1 and the device ID code 0x2245. This
confirms basic read/write functionality of the flash devices.
8.8. Summary
For most flash devices in use today, programming involves state machine like cycles of multiple writes
that must proceed the final write cycle. To diagnose flash programming failures, you must determine
whether the cause of the failure is in target hardware or flash programming software. The general
method of document lets you make this determination through simple, low level writes and reads,
without the use of expensive and complicated logic analyzers. If these reads and writes fail, the problem
most likely is on the target. If these reads and writes succeed, the problem most likely is in the flash
programming software, so contact Technical Support at: http://www.freescale.com/support.
Freescale Semiconductor reserves the right to make changes without further notice to any products
herein. Freescale Semiconductor makes no warranty, representation or guarantee regarding the
suitability of its products for any particular purpose, nor does Freescale Semiconductor assume any
liability arising out of the application or use of any product or circuit, and specifically disclaims any and
all liability, including without limitation consequential or incidental damages. “Typical” parameters that
may be provided in Freescale Semiconductor data sheets and/or specifications can and do vary in
different applications and actual performance may vary over time. All operating parameters, including
“Typicals”, must be validated for each customer application by customer’s technical experts. Freescale
Semiconductor does not convey any license under its patent rights nor the rights of others. Freescale
Semiconductor products are not designed, intended, or authorized for use as components in systems
intended for surgical implant into the body, or other applications intended to support or sustain life, or for
any other application in which the failure of the Freescale Semiconductor product could create a
situation where personal injury or death may occur. Should Buyer purchase or use Freescale
Semiconductor products for any such unintended or unauthorized application, Buyer shall indemnify and
hold Freescale Semiconductor and its officers, employees, subsidiaries, affiliates, and distributors
harmless against all claims, costs, damages, and expenses, and reasonable attorney fees arising out of,
directly or indirectly, any claim of personal injury or death associated with such unintended or
unauthorized use, even if such claim alleges that Freescale Semiconductor was negligent regarding the
design or manufacture of the part.
Freescale, the Freescale logo, CodeWarrior, and QorIQ are trademarks of Freescale Semiconductor,
Inc., Reg. U.S. Pat. & Tm. Off. Layerscape is trademark of Freescale Semiconductor, Inc. All other
product or service names are the property of their respective owners. ARM, Cortex, Cortex-A7,
TrustZone are trademarks of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. All rights
reserved.