STMicroelectronics C90FL Flash module User manual
Mainos
Mainos
UM1620
User manual
Standard software driver for C90FL
Introduction
This document is the user manual for the Standard Software Driver (SSD) for single C90
Flash module.
The SSD is a set of API’s that enables user application to operate on the Flash module embedded on a microcontroller. The C90FL SSD contains a set of functions to program/erase a single C90FL Flash module.
The C90FL Standard Software Driver (SSD) provides the following API’s:
•
FlashInit
•
FlashErase
•
BlankCheck
•
FlashProgram
•
ProgramVerify
•
CheckSum
•
FlashSuspend
•
FlashResume
•
GetLock
•
SetLock
•
FlashArrayIntegrityCheck
•
FlashECCLogicCheck
•
FactoryMarginReadCheck
September 2013 DocID024388 Rev 3 1/41
www.st.com
Contents
Contents
UM1620
Configuration parameters and macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Normal mode functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
FlashArrayIntegrityCheck() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
FlashECCLogicCheck() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
FactoryMarginReadCheck() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2/41 DocID024388 Rev 3
UM1620 Contents
DocID024388 Rev 3 3/41
List of tables
List of tables
UM1620
4/41 DocID024388 Rev 3
UM1620 List of tables
Table 60.
Document revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
DocID024388 Rev 3 5/41
Introduction
1 Introduction
UM1620
This document is the user manual for the Standard Software Driver (SSD) for single C90FL
Flash module. The road-map for the document is as follows.
shows the features of the driver.
Appendix B: System requirements
details the
system requirement for the driver development. Appendix D: Document reference
lists the documents referred and terms used in making of this document.
lists the acronyms used.
describes the API specifications. In this section there are many sub sections,
which describe the different aspects of the driver. Section 2.1
provides a general overview of the driver.
Section 2.2 mentions about the type definitions used for the driver. Section 2.3
mentions the
driver configuration parameters and configuration macros respectively.
describe the CallBack notifications, and return codes used for the driver.
provide the detailed description of normal mode and special mode standard software Flash Driver APIs’ respectively.
provides the performance indexes.
1.2 Features
The C90FL SSD provides the following features:
•
Two sets of driver binaries built on Power Architecture instruction set technology and
Variable-Length-Encoding (VLE) instruction set.
•
Drivers released in binary c-array format to provide compiler-independent support for non-debug-mode embedded applications.
•
Drivers released in s-record format to provide compiler-independent support for debugmode/JTAG programming tools.
•
Each driver function is independent of each other so the end user can choose the function subset to meet their particular needs.
•
Support page-wise programming for fast programming.
•
Position-independent and ROM-able
•
Ready-to-use demos illustrating the usage of the driver
•
Concurrency support via callback
6/41 DocID024388 Rev 3
UM1620 API specification
2.2
2.3
The C90FL SSD has APIs to handle the erase, program, erase verify and program verify operations on the Flash. Apart from these, it also provides the feature for locking specific blocks and calculating Check sum. This SSD also provides 3 user test APIs for checking the
Array Integrity and the ECC Logic.
General type definitions
Derived type
BOOL
INT8
VINT8
UINT8
VUINT8
INT16
VINT16
UINT16
VUINT16
INT32
VINT32
UINT32
VUINT32
8-bits
8-bits
8-bits
8-bits
8-bits
16-bits
16-bits
16-bits
16-bits
32-bits
32-bits
32-bits
32-bits
Table 1. Type definitions
Size C language type description
unsigned char signed char volatile signed char unsigned char volatile unsigned char signed short volatile signed short unsigned short volatile unsigned short signed long volatile signed long unsigned long volatile unsigned long
Configuration parameters and macros
The configuration parameter which is used for SSD operations is explained in this section.
The configuration parameters are handled as structure. The user should correctly initialize the fields including c90flRegBase, mainArrayBase, shadowRowBase, shadowRowSize,
pageSize
and BDMEnable before passing the structure to SSD functions. The pointer to
CallBack
has to be initialized either to a null pointer or a valid CallBack function pointer.
Table 2. SSD configuration structure field definition
Parameter name Type Parameter description
c90flRegBase mainArrayBase mainArraySize
UINT32
UINT32
UINT32
The base address of C90FL and BIU control registers.
The base address of Flash main array.
The size of Flash main array in byte.
DocID024388 Rev 3 7/41
API specification UM1620
Table 2. SSD configuration structure field definition (continued)
Parameter name Type Parameter description
shadowRowBase shadowRowSize shadowRowSize lowBlockNum midBlockNum highBlockNum pageSize
BDMEnable
UINT32
UINT32
UINT32
UINT32
UINT32
UINT32
UINT32
UINT32
The base address of shadow row
The size of shadow row in byte.
Number of blocks of the large address space (128K or 256K).
Block number of the low address space.
Block number of the mid address space.
Block number of the high address space.
The page size of the C90FL Flash
Defines the state of background debug mode (enable
/disable)
Note:
The type definition for the structure is given below.
typedef struct _ssd_config
{
UINT32 c90flRegBase;
UINT32 mainArrayBase;
UINT32 mainArraySize;
UINT32 shadowRowBase;
UINT32 shadowRowSize;
UINT32 lowBlockNum;
UINT32 midBlockNum;
UINT32 highBlockNum;
UINT32 pageSize;
UINT32 BDMEnable;
} SSD_CONFIG, *PSSD_CONFIG;
The macro value COMPILER_SELECT should be set to
CODE_WARRIOR – if CodeWarrior compiler is used for compiling
DIAB_COMPILER – if Diab compiler is used for compiling
The Standard Software Driver facilitates the user to supply a pointer to ‘CallBack()’ function so that time-critical events can be serviced during C90FL Standard Software driver operations.
Servicing watchdog timers is one such time critical event. If it is not necessary to provide the
CallBack service, the user is able to disable it by a NULL function macro.
#define NULL_CALLBACK ((void *) 0xFFFFFFFF)
The job processing callback notifications shall have no parameters and no return value.
8/41 DocID024388 Rev 3
UM1620 API specification
The return code is returned to the caller function to notify the success or errors of the API execution. These are the possible values of return code:
Name
Table 3. Return codes
Value Description
C90FL_OK
C90FL_INFO_RWE
C90FL_INFO_EER
C90FL_ERROR_ALIGNMENT
C90FL_ERROR_RANGE
C90FL_ERROR_BUSY
C90FL_ERROR_PGOOD
C90FL_ERROR_EGOOD
C90FL_ERROR_NOT_BLANK
C90FL_ERROR_VERIFY
0x00000000 The requested operation is successful.
0x00000001 RWE bit is set before Flash operations.
0x00000002 EER bit is set before Flash operations.
0x00000100 Alignment error.
0x00000200 Address range error.
0x00000300
New program/erase cannot be preformed while a high voltage operation is already in progress.
0x00000400 The program operation is unsuccessful.
0x00000500 The erase operation is unsuccessful.
0x00000600
There is a non-blank Flash memory location within the checked Flash memory region.
0x00000700
There is a mismatch between the source data and the content in the checked Flash memory.
C90FL_ERROR_LOCK_INDICATOR 0x00000800 Invalid block lock indicator.
C90FL_ERROR_RWE
C90FL_ERROR_PASSWORD
0x00000900
0x00000A00
Read-while-write error occurred in previous reads.
The password provided cannot unlock the block lock register for register writes
C90FL_ERROR_AIC_MISMATCH 0x00000B00
In ‘FlashArrayIntegrityCheck()’ the MISR values generated by the hardware do not match the values passed by the user.
C90FL_ERROR_AIC_NO_BLOCK
C90FL_ERROR_FMR_MISMATCH
C90FL_ERROR_FMR_NO_BLOCK
C90FL_ERROR_ECC_LOGIC
0x00000C00
0x00000D00
0x00000E00
0x00000F00
In ‘FlashArrayIntegrityCheck()’ no blocks have been enabled for Array Integrity check
In ‘FactoryMarginReadCheck()’ the MISR values generated by the hardware do not match the values passed by the user.
In ‘FactoryMarginReadCheck()’ no blocks have been enabled for Array Integrity check
In ‘FlashECCLogicCheck()’ the simulated
ECC error has not occurred.
DocID024388 Rev 3 9/41
API specification UM1620
2.6.1 FlashInit()
Description
This function reads the Flash configuration information from the Flash control registers and initialize parameters in SSD configuration structure. ‘FlashInit()’ must be called prior to any other Flash operations.
Prototype
UINT32 FlashInit (PSSD_CONFIG pSSDConfig);
Arguments
Argument
pSSDConfig
Table 4. Arguments for FlashInit()
Description Range
Pointer to the SSD
Configuration Structure.
The values in this structure are chip-dependent.
Return values
Type
UINT32
Table 5. Return values for FlashInit()
Description Possible values
Indicates either success or failure type. It is a bit mapped return code so that more than one condition can be returned with a single return code. Each bit in the returned value, except for C90FL_OK, indicates a kind of current status of C90FL module.
C90FL_OK
C90FL_INFO_EER
C90FL_INFO_RWE
Troubleshooting
None.
Comments
‘FlashInit()’ checks the C90FL_MCR_RWE and C90FL_MCR_EER bit, and clear them when any of them is set. If RWE bit is set, Flash program/erase operations can still be performed.
Assumptions
The user must correctly initialize the fields including c90flRegBase, mainArrayBase,
shadowRowBase, shadowRowSize, pageSize and BDMEnable before passing the structure to the FlashInit() functions
.
10/41 DocID024388 Rev 3
UM1620 API specification
2.6.2 FlashErase()
Description
This function erases the enabled blocks in the main array or the shadow row. Input arguments together with relevant Flash module status are checked, and relevant error code is returned if there is any error.
Prototype
UINT32 FlashErase (PSSD_CONFIG pSSDConfig,
BOOL shadowFlag,
UINT32 lowEnabledBlocks,
UINT32 midEnabledBlocks,
UINT32 highEnabledBlocks, void (*CallBack)(void));
Arguments
Argument
pSSDConfig shadowFlag lowEnabledBlocks midEnabledBlocks highEnabledBlocks
CallBack
Table 6. Arguments for FlashErase()
Description Range
Pointer to the SSD
Configuration Structure.
The values in this structure are chip-dependent.
Please refer to
for more details.
Indicate either the main array or the shadow row to be erased.
TRUE: the shadow row is erased. The
lowEnabledBlocks, midEnabledBlocks and
highEnabledBlocks are ignored;
FALSE: The main array is erased. Which blocks are erased in low, mid and high address spaces are specified by lowEnabledBlocks, midEnabledBlocks and highEnabledBlocks respectively.
To select the array blocks in low address space for erasing.
To select the array blocks in mid address space for erasing.
To select the array blocks in high address space for erasing.
Address of void call back function pointer.
Bit-mapped value. Select the block in the low address space to be erased by setting 1 to the appropriate bit of lowEnabledBlocks. If there is not any block to be erased in the low address space,
lowEnabledBlocks must be set to 0.
Bit-mapped value. Select the block in the middle address space to be erased by setting 1 to the appropriate bit of midEnabledBlocks. If there is not any block to be erased in the middle address space,
midEnabledBlocks must be set to 0.
Bit-mapped value. Select the block in the high address space to be erased by setting 1 to the appropriate bit of highEnabledBlocks. If there is not any block to be erased in the high address space,
highEnabledBlocks must be set to 0.
Any addressable void function address. To disable it use NULL_CALLBACK macro.
DocID024388 Rev 3 11/41
API specification
Return values
Type
UINT32
Table 7. Return values for FlashErase()
Description Possible values
Successful completion or error value.
C90FL_OK
C90FL_ERROR_BUSY
C90FL_ERROR_EGOOD
UM1620
Troubleshooting
Error codes
C90FL_ERROR_BUSY
Table 8. Troubleshooting for FlashErase()
Possible causes
New erase operation cannot be performed because there is program/erase sequence in progress on the Flash module.
C90FL_ERROR_ EGOOD Erase operation failed.
Solution
Wait until all previous program/erase operations on the
Flash module finish.
Possible cases that erase cannot start are:
– erase in progress
(FLASH_MCR-ERS is high);
– program in progress
(FLASH_MCR-PGM is high);
Check if the C90FL is available and high voltage is applied to
C90FL. Then try to do the erase operation again.
Comments
When shadowFlag is set to FALSE, the ‘FlashErase()’ function erases the blocks in the main array. It is capable of erasing any combination of blocks in the low, mid and high address spaces in one operation. If shadowFlag is TRUE, this function erases the shadow row.
The inputs lowEnabledBlocks, midEnabledBlocks and highEnabledBlocks are bit-mapped arguments that are used to select the blocks to be erased in the Low/Mid/High address spaces of main array. The selection of the blocks of the main array is determined by setting/clearing the corresponding bit in lowEnabledBlocks, midEnabledBlocks or
highEnabledBlocks.
The bit allocations for blocks in one address space are: bit 0 is assigned to block 0, bit 1 to block 1, etc. The following diagrams show the formats of lowEnabledBlocks,
midEnabledBlocks and highEnabledBlocks for the C90FL module.
For low address space valid bits are from bit 0 to bit (lowBlockNum – 1). In which,
lowBlockNum
is the number of low blocks returned from FlashInit();
For middle address space valid bits are from bit 0 and bit (midBlockNum – 1). In which,
midBlockNum
is the number of middle blocks returned from FlashInit();
For high address space valid bits are from bit 0 to bit (highBlockNum – 1). In which,
highBlockNum
is the number of high blocks returned from FlashInit();
12/41 DocID024388 Rev 3
UM1620 API specification
For example, below are bit allocations for blocks in Low/Mid/High Address Space of
SPC564A70:
Table 9. Bit allocation for blocks in low address space
MSB bit 31
reserved
…
…
bit 10
reserved
bit 9
block 9
bit 8
block 8
…
…
bit 1
block 1
LSB bit 0
block 0
MSB bit 31
reserved
Table 10. Bit allocation for blocks in middle address space
…
…
bit 4 bit 3 bit 2 bit 1
reserved reserved reserved block 1
LSB bit 0
block 0
MSB bit 31
reserved
Table 11. Bit allocation for blocks in high address space
…
…
bit 6
reserved
bit 5
block 5
bit 4
block 4
…
…
bit 1
Block 1
LSB bit 0
Block 0
If the selected main array blocks or the shadow row is locked for erasing, those blocks or the shadow row are not erased, but ‘FlashErase()’ still returns C90FL_OK. User needs to check the erasing result with the ‘BlankCheck()’ function.
It is impossible to erase any Flash block or shadow row when a program or erase operation is already in progress on C90FL module. ‘FlashErase()’ returns C90FL_ERROR_BUSY when trying to do so. Similarly, once an erasing operation has started on C90FL module, it is impossible to run another program or erase operation.
In addition, when ‘FlashErase()’ is running, it is unsafe to read the data from the Flash module having one or more blocks being erased. Otherwise, it causes a Read-While-Write error.
Assumptions
It assumes that the Flash block is initialized using a ‘FlashInit()’ API. User provides the correct ssdconfig parameters to FlashErase() as returned by FlashInit().
2.6.3 BlankCheck()
Description
This function checks on the specified Flash range in the main array or shadow row for blank state. If the blank checking fails, the first failing address and the failing data in Flash block are saved.
DocID024388 Rev 3 13/41
API specification UM1620
Prototype
UINT32 BlankCheck (PSSD_CONFIG pSSDConfig,
UINT32 dest,
UINT32 size,
UINT32 * pFailAddress,
UINT64 *pFailData, void (*CallBack) (void ));
Arguments
Argument
pSSDConfig dest size pFailAddress pFailData
CallBack
Table 12. Arguments for BlankCheck()
Description Range
Pointer to the SSD
Configuration Structure.
Destination address to be checked.
The values in this structure are chip-dependent.
Any accessible address aligned on double word boundary in main array or shadow row
Size, in bytes, of the Flash region to check.
If size = 0, the return value is C90FL_OK.
It should be multiple of 8 and its combination with
dest should fall in either main array or shadow row.
Return the address of the first non-blank Flash location in the checking region.
Only valid when this function returns
C90FL_ERROR_NOT_BLANK.
Return the content of the first non-blank Flash location in the checking region.
Only valid when this function returns
C90FL_ERROR_NOT_BLANK.
Address of void callback function.
Any addressable void function address. To disable it use NULL_CALLBACK macro.
Return values
Type
UINT32
Table 13. Return values for BlankCheck()
Description Possible values
Successful completion or error value.
C90FL_OK
C90FL_ERROR_ALIGNMENT
C90FL_ERROR_RANGE
C90FL_ERROR_NOT_BLANK
14/41 DocID024388 Rev 3
UM1620 API specification
Troubleshooting
Table 14. Troubleshooting for BlankCheck()
Returned error bits Description Solution
C90FL_ERROR_ALIGNMENT
C90FL_ERROR_RANGE
C90FL_ERROR_NOT_BLANK
The dest/size are not properly aligned.
Check if dest and size are aligned on double word (64-bit) boundary.
The area specified by dest and size is out of the valid
C90FL array ranges.
Check dest and dest+size. The area to be checked must be within main array space or shadow space.
There is a non-blank double word within the area to be checked.
Erase the relevant blocks and check again.
Comments
If the blank checking fails, the first failing address is saved to *pFailAddress, and the failing data in Flash is saved to *pFailData. The contents pointed by
pFailAddress and pFailData are updated only when there is a non-blank location in
the checked Flash range.
Assumptions
It assumes that the Flash block is initialized using a ‘FlashInit()’ API.
2.6.4 FlashProgram()
Description
This function programs the specified Flash areas with the provided source data. Input arguments together with relevant Flash module status are checked, and relevant error code is returned if there is any error.
Prototype
UINT32 FlashProgram (PSSD_CONFIG pSSDConfig,
UINT32 dest,
UINT32 size,
UINT32 source, void (*CallBack)(void));
Arguments
Argument
pSSDConfig
Dest
Table 15. Arguments for FlashProgram()
Description Range
Pointer to the SSD
Configuration Structure.
Destination address to be programmed in Flash memory.
The values in this structure are chip-dependent.
Please refer to
for more details.
Any accessible address aligned on double word boundary in main array or shadow row.
DocID024388 Rev 3 15/41
API specification UM1620
Argument
Size source
CallBack
Table 15. Arguments for FlashProgram() (continued)
Description Range
Size, in bytes, of the Flash region to be programmed.
If size = 0, C90FL_OK is returned.
It should be multiple of 8 and its combination with dest should fall in either main array or shadow row.
Source program buffer address.
This address must reside on word boundary.
Address of void call back function pointer.
Any addressable void function address. To disable it use NULL_CALLBACK macro.
Return values
Type
UINT32
Table 16. Return values for FlashProgram()
Description Possible values
Successful completion or error value.
C90FL_OK
C90FL_ERROR_BUSY
C90FL_ERROR_ALIGNMENT
C90FL_ERROR_RANGE
C90FL_ERROR_PGOOD
Troubleshooting
Table 17. Troubleshooting for FlashProgram()
Returned error bits Description Solution
C90FL_ERROR_BUSY
C90FL_ERROR_ALIGNMENT
C90FL_ERROR_RANGE
C90FL_ERROR_PGOOD
New program operation cannot be performed because the Flash module is busy with some operation and cannot meet the condition for starting a program operation.
This error indicates that
dest/size/source isn’t properly aligned
Wait until the current operations finish.
Conditions that program cannot start are:
1. program in progress (MCR-PGM high);
2. program not in progress (MCR-PGM low), but:
– erase in progress but not suspended;
– erase on main array is suspended but program is targeted to shadow row;
– erase on shadow row is suspended.
Check if dest and size are aligned on double word (64-bit) boundary. Check if source is aligned on word boundary.
The area specified by
dest and size is out of the valid C90FL address range.
Check dest and dest+size. Both should fall in the same C90FL address ranges, i.e. both in main array or both in shadow row
Program operation failed because this operation cannot pass PEG check.
Repeat the program operation. Check if the C90FL is invalid or high voltage applied to C90FL is unsuitable.
16/41 DocID024388 Rev 3
UM1620 API specification
Comments
If the selected main array blocks or the shadow row is locked for programming, those blocks or the shadow row are not programmed, and ‘FlashProgram()’ still returns C90FL_OK. User needs to verify the programmed data with ‘ProgramVerify()’ function.
It is impossible to program any Flash block or shadow row when a program or erase operation is already in progress on C90FL module. ‘FlashProgram()’ returns
C90FL_ERROR_BUSY when doing so. However, user can use the ‘FlashSuspend()’ function to suspend an on-going erase operation on one block to perform a program operation on another block. The user has begun an erase operation on the main array or shadow row, it may be suspended to program on both main array and shadow row.
It is unsafe to read the data from the Flash partitions having one or more blocks being programmed when ‘FlashProgram()’ is running. Otherwise, it causes a Read-While-Write error.
Assumptions
It assumes that the Flash block is initialized using a ‘FlashInit()’ API.
2.6.5 ProgramVerify()
Description
This function checks if a programmed Flash range matches the corresponding source data buffer. In case of mismatch, the failed address, destination value and source value are saved and relevant error code is returned.
Prototype
UINT32 ProgramVerify (PSSD_CONFIG pSSDConfig,
UINT32 dest,
UINT32 size,
UINT32 source,
UINT32 *pFailAddress,
UINT64 *pFailData,
UINT64 *pFailSource, void (*CallBack)(void));
Arguments
Argument
pSSDConfig
Dest
Size
Source
Table 18. Arguments for ProgramVerify()
Description Range
Pointer to the SSD
Configuration Structure.
Destination address to be verified in Flash memory.
The values in this structure are chip-dependent.
Please refer to
for more details.
Any accessible address aligned on double word boundary in main array or shadow row.
Size, in byte, of the Flash region to verify.
If size = 0, C90FL_OK is returned. Its combination with dest should fall within either main array or shadow row.
Verify source buffer address. This address must reside on word boundary.
DocID024388 Rev 3 17/41
API specification UM1620
Argument
pFailAddress pFailData pFailSource
CallBack
Table 18. Arguments for ProgramVerify() (continued)
Description Range
Return first failing address in
Flash.
Only valid when the function returns
C90FL_ERROR_VERIFY.
Returns first mismatch data in Flash.
Only valid when this function returns
C90FL_ERROR_VERIFY.
Returns first mismatch data in buffer.
Only valid when this function returns
C90FL_ERROR_VERIFY.
Address of void call back function pointer.
Any addressable void function address. To disable it use NULL_CALLBACK macro.
Return values
Type
UINT32
Table 19. Return values for ProgramVerify()
Description Possible values
Successful completion or error value.
C90FL_OK
C90FL_ERROR_ALIGNMENT
C90FL_ERROR_RANGE
C90FL_ERROR_VERIFY
Troubleshooting
Table 20. Troubleshooting for ProgramVerify()
Returned error bits Description Solution
C90FL_ERROR_ALIGNMENT
C90FL_ERROR_RANGE
C90FL_ERROR_VERIFY
This error indicates that
dest/size/source isn’t properly aligned
Check if dest and size are aligned on double word (64-bit) boundary. Check if
source is aligned on word boundary
The area specified by
dest and size is out of the valid C90FL address range.
Check dest and dest+size, both should fall in the same C90FL address ranges, i.e. both in main array or both in shadow row
The content in C90FL and source data mismatch.
Check the correct source and destination addresses, erase the block and reprogram data into Flash.
Comments
The contents pointed by pFailLoc, pFailData and pFailSource are updated only when there is a mismatch between the source and destination regions.
Assumptions
It assumes that the Flash block is initialized using a ‘FlashInit()’ API.
18/41 DocID024388 Rev 3
UM1620 API specification
2.6.6 CheckSum()
Description
This function performs a 32-bit sum over the specified Flash memory range without carry, which provides a rapid method for checking data integrity.
Prototype
UINT32 CheckSum (PSSD_CONFIG pSSDConfig,
UINT32 dest,
UINT32 size,
UINT32 *pSum, void (*CallBack)(void));
Arguments
Argument
pSSDConfig
Dest
Size pSum
CallBack
Table 21. Arguments for CheckSum()
Description Range
Pointer to the SSD
Configuration Structure.
The values in this structure are chip-dependent.
Please refer to
for more details.
Destination address to be summed in Flash memory.
Any accessible address aligned on double word boundary in either main array or shadow row.
Size, in bytes, of the Flash region to check sum.
If size is 0 and the other parameters are all valid,
C90FL_OK is returned. Its combination with dest should fall within either main array or shadow row.
Returns the sum value.
Address of void call back function pointer.
0x00000000 - 0xFFFFFFFF. Note that this value is only valid when the function returns C90FL_OK.
Any addressable void function address. To disable it use NULL_CALLBACK macro.
Return values
Type
UINT32
Table 22. Return values for CheckSum()
Description Possible values
Successful completion or error value.
C90FL_OK
C90FL_ERROR_ALIGNMENT
C90FL_ERROR_RANGE
DocID024388 Rev 3 19/41
API specification UM1620
Troubleshooting
Table 23. Troubleshooting for CheckSum()
Returned error bits Description Solution
C90FL_ERROR_ALIGNMENT
C90FL_ERROR_RANGE
This error indicates that
dest/size isn’t properly aligned.
Check if dest and size are aligned on double word (64-bit) boundary. Check if
source is aligned on word boundary.
The area specified by
dest and size is out of the valid C90FL address range.
Check dest and dest+size, both should fall in the same C90FL address ranges, i.e. both in main array or both in shadow row.
Comments
None.
Assumptions
It assumes that the Flash block is initialized using a ‘FlashInit()’ API
.
2.6.7 FlashSuspend()
Description
This function checks if there is any high voltage operation, erase or program, in progress on the C90FL module and if the operation can be suspended. This function suspends the ongoing operation if it can be suspended.
Prototype
UINT32 FlashSuspend (PSSD_CONFIG pSSDConfig,
UINT8 *suspendState,
BOOL *suspendFlag);
Arguments
Argument
pSSDConfig suspendState suspendFlag
Table 24. Arguments for FlashSuspend()
Description Range
Pointer to the SSD
Configuration Structure.
The values in this structure are chip-dependent.
Please refer to
for more details.
Indicate the suspend state of C90FL module after the function being called.
All return values are enumerated in
.
Return whether the suspended operation, if there is any, is suspended by this call.
TRUE: the operation is suspended by this call;
FALSE: either no operation to be suspended or the operation is suspended not by this call.
20/41 DocID024388 Rev 3
UM1620 API specification
Return values
Type
UINT32
Table 25. Return values for FlashSuspend()
Description Possible values
Successful completion.
C90FL_OK
Troubleshooting
None.
Comments
After calling ‘FlashSuspend()’, read is allowed on both main array space and shadow row without any Read-While-Write error. But data read from the blocks targeted for programming or erasing is indeterminate even if the operation is suspended.
This function should be used together with ‘FlashResume()’. The suspendFlag returned by
‘FlashSuspend()’ determine whether ‘FlashResume()’ needs to be called or not. If suspendFlag is TRUE, ‘FlashResume()’ must be called symmetrically to resume the suspended operation.
Following table defines and describes various suspend states and associated suspend codes.
Argument
NO_OPERTION
PGM_WRITE
ERS_WRITE
Table 26. suspendState definitions
Code Description Valid operation after suspend
0
1
2
ERS_SUS_PGM_WRITE 3
PGM_SUS
ERS_SUS
4
5
There is no program/erase operation.
Erasing operation, programming operation and read are valid on both main array space and shadow row.
There is a program sequence in interlock write stage.
There is an erase-suspend program sequence in interlock write stage.
Only read is valid on both main array space and shadow row.
There is an erase sequence in interlock write stage.
Only read is valid on both main array space and shadow row.
Only read is valid on both main array space and shadow row.
The program operation is in suspended state.
Only read is valid on both main array space and shadow row.
The erase operation on main array is in suspended state.
Programming operation is valid only on main array space. Read is valid on both main array space and shadow row.
DocID024388 Rev 3 21/41
API specification UM1620
Argument
SHADOW_ERS_SUS
ERS_SUS_PGM_SUS
Table 26. suspendState definitions (continued)
Code Description Valid operation after suspend
6
7
The erase operation on shadow row is in suspended state.
Read is valid on both main array space and shadow space.
The erase-suspended program operation is in suspended state.
Only read is valid on both main array space and shadow row.
The table below lists the Suspend Flag values returned against the Suspend State and the
Flash block status.
Table 27. Suspending state and flag vs. C90FL status suspendState EHV ERS ESUS PGM PSUS PEAS suspendFlag
NO_OPERATION
PGM_WRITE
ERS_WRITE
ESUS_PGM_WRITE
PGM_SUS
ERS_SUS
SHADOW_ERS_SUS
ERS_SUS_PGM_SUS
X
X
0
X
X
X
X
0
1
1
X
X
0
1
X
X
0
X
0
X
X
X
0
1
1
1
0
0
1
0
1
0
0
0
1
1
X
X
0
0
1
X
X
1
0
1
1
1
0
0
1
1
1
0
0
1
1
1
1
1
1
X
1
0
0
X
0
X
1
X
1
X
FALSE
FALSE
FALSE
FALSE
TRUE
FALSE
TRUE
FALSE
TRUE
FALSE
TRUE
FALSE
The values of EHV, ERS, ESUS, PGM, PSUS and PEAS represent the C90FL status at the entry of FlashSuspend;
0: Logic zero; 1: Logic one; X: Do-not-care
.
Assumptions
It assumes that the Flash block is initialized using a ‘FlashInit()’ API.
2.6.8 FlashResume()
Description
This function checks if there is any suspended erase or program operation on the C90FL module, and resumes the suspended operation if there is any.
22/41 DocID024388 Rev 3
UM1620 API specification
Prototype
UINT32 FlashResume (PSSD_CONFIG pSSDConfig,
UINT8 *resumeState);
Arguments
Argument
pSSDConfig resumeState
Table 28. Arguments for FlashResume()
Description Range
Pointer to the SSD
Configuration Structure.
The values in this structure are chip-dependent.
Indicate the resume state of
C90FL module after the function being called.
All return values are listed in
.
Return values
Type
UINT32
Table 29. Return values for FlashResume()
Description Possible values
Successful completion.
C90FL_OK
Troubleshooting
None.
Comments
This function resumes one operation if there is any operation is suspended. For instance, if a program operation is in suspended state, it is resumed. If an erase operation is in suspended state, it is resumed too. If an erase-suspended program operation is in suspended state, the program operation is resumed prior to resuming the erase operation. It is better to call this function based on suspendFlag returned from ‘FlashSupend()’.
Following table defines and describes various resume states and associated resume codes.
Code name
RES_NOTHING
RES_PGM
RES_ERS
RES_ERS_PGM
0
1
2
3
Table 30. resumeState definitions
Value Description
No program/erase operation to be resumed
A program operation is resumed
A erase operation is resumed
A suspended erase-suspended program operation is resumed
Assumptions
It assumes that the Flash block is initialized using a ‘FlashInit()’ API.
DocID024388 Rev 3 23/41
API specification UM1620
2.6.9 GetLock()
Description
This function checks the block locking status of Shadow/Low/Middle/High address spaces in the C90FL module.
Prototype
UINT32 GetLock (PSSD_CONFIG pSSDConfig,
UINT8 blkLockIndicator,
BOOL *blkLockEnabled,
UINT32 *blkLockState);
Arguments
Argument
pSSDConfig blkLockIndicator blkLockEnabled blkLockState
Table 31. Arguments for GetLock()
Description Range
Pointer to the SSD
Configuration Structure.
The values in this structure are chip-dependent.
Please refer to
for more details.
Indicating the address space and the block locking level, which determines the address space block locking register to be checked.
Refer to
for valid values for this parameter.
Indicate whether the address space block locking register is enabled for register writes
TRUE – The address space block locking register is enabled for register writes.
FALSE – The address space block locking register is disabled for register writes.
Returns the blocks’ locking status of indicated locking level in the given address space
Bit mapped value indicating the locking status of the specified locking level and address space.
1: The block is locked from program/erase.
0: The block is ready for program/erase
Return values
Type
UINT32
Table 32. Return values for GetLock()
Description Possible values
Successful completion or error value.
C90FL_OK
C90FL_ERROR_LOCK_INDICATOR
Troubleshooting
Table 33. Troubleshooting for GetLock()
Returned error bits Possible causes Solution
C90FL_ERROR_LOCK_INDICATOR
The input blkLockIndicator is invalid.
Set this argument to correct
24/41 DocID024388 Rev 3
UM1620 API specification
Comments
Following table defines and describes various blkLockIndicator values.
Code Name
LOCK_SHADOW_PRIMARY
Table 34. blkLockIndicator definitions
Value Description
0
LOCK_SHADOW_SECONDARY 1
LOCK_LOW_PRIMARY
LOCK_LOW_SECONDARY
LOCK_MID_PRIMARY
LOCK_MID_SECONDARY
LOCK_HIGH
2
3
4
5
6
Primary block lock protection of shadow address space
Secondary block lock protection of shadow address space
Primary block lock protection of low address space
Secondary block lock protection of low address space
Primary block lock protection of mid address space
Secondary block lock protection of mid address space
Block lock protection of high address space
For Shadow/Low/Mid address spaces, there are two block lock levels. The secondary level of block locking provides an alternative means to protect blocks from being modified. A logical “OR” of the corresponding bits in the primary and secondary lock registers for a block determines the final lock status for that block. For high address space there is only one block lock level.
The output parameter blkLockState returns a bit-mapped value indicating the block lock status of the specified locking level and address space. A main array block or shadow row is locked from program/erase if its corresponding bit is set.
The indicated address space determines the valid bits of blkLockState. The following diagrams show the block bitmap definitions of blkLockState for shadow/Low/Mid/High address spaces.
For low address space valid bits are from bit 0 to bit (lowBlockNum – 1). In which,
lowBlockNum
is the number of low blocks returned from FlashInit();
For middle address space valid bits are from bit 0 and bit (midBlockNum – 1). In which,
midBlockNum
is the number of middle blocks returned from FlashInit();
For high address space valid bits are from bit 0 to bit (highBlockNum – 1). In which,
highBlockNum
is the number of high blocks returned from FlashInit();
For shadow row valid bit is bit 0;
For example, below are bit allocations for blocks in Low/Mid/High Address Space of
SPC564A70:
Table 35. blkLockState bit allocation for shadow address space
MSB bit 31
reserved …
…
LSB bit 1 bit 0
reserved shadow row
DocID024388 Rev 3 25/41
API specification UM1620
MSB bit 31
reserved
Table 36. blkLockState bit allocation for low address space
…
…
bit 10 bit 9
reserved block 9
bit 8
block 8
…
…
LSB bit 1 bit 0
block 1 block 0
MSB bit 31
reserved
Table 37. blkLockState bit allocation for mid address space
…
…
LSB bit 4 bit 3 bit 2 bit 1 bit 0
reserved reserved reserved block 1 block 0
MSB bit 31
reserved
Table 38. blkLockState bit allocation for high address space
…
…
bit 6 bit 5
reserved block 5
bit 4
block 4
…
…
LSB bit 1 bit 0
block 1 block 0
Assumptions
It assumes that the Flash block is initialized using a ‘FlashInit()’ API.
2.6.10 SetLock()
Description
This function sets the block lock state for Shadow/Low/Middle/High address space on the
C90FL module to protect them from program/erase. The API provides password to enable block lock register writes when is needed and write the block lock value to block lock register for the requested address space.
Prototype
UINT32 SetLock (PSSD_CONFIG pSSDConfig,
UINT8 blkLockIndicator,
UINT32 blkLockState,
UINT32 password);
26/41 DocID024388 Rev 3
UM1620 API specification
Arguments
Table 39. Arguments for SetLock()
Description Range Argument
pSSDConfig blkLockIndicator blkLockState password
Pointer to the SSD
Configuration Structure.
Indicating the address space and the protection level of the block lock register to be read.
The values in this structure are chip-dependent.
Please refer to
Refer to
for more details.
for valid codes for this parameter.
The block locks to be set to the specified address space and protection level.
Bit mapped value indicating the lock status of the specified protection level and address space.
1: The block is locked from program/erase.
0: The block is ready for program/erase
A password is required to enable the block lock register for register write.
Correct passwords for block lock registers are
0xA1A1_1111 for Low/Mid Address Space Block
Locking Register, 0xC3C3_3333 for Secondary
Low/Mid Address Space Block Locking Register, and 0xB2B2_2222 for High Address Space Block
Select Register.
Return values
Type
UINT32
Table 40. Return values for SetLock()
Description Possible values
Successful completion or error value.
C90FL_OK
C90FL_ERROR_LOCK_INDICATOR
C90FL_ERROR_PASSWORD
Troubleshooting
The troubleshooting mentioned below comprises of hardware errors due to both P Flash block erase verify and P Flash section erase verify command. Apart from these the input based error handling is also mentioned.
Table 41. Troubleshooting for SetLock()
Returned error bits Possible causes Solution
C90FL_ERROR_LOCK_INDICATOR
C90FL_ERROR_PASSWORD
The input blkLockIndicator is invalid.
Set this argument to correct
.
The given password cannot enable the block lock register for register writes.
Pass in a correct password.
Comments
The bit field allocation for blkLockState is same as that in ‘GetLock()’ function.
DocID024388 Rev 3 27/41
API specification
Assumptions
It assumes that the Flash block is initialized using a ‘FlashInit()’ API.
UM1620
2.7 User test mode functions
2.7.1 FlashArrayIntegrityCheck()
Description
This function checks the array integrity of the Flash. The user specified address sequence is used for array integrity reads and the operation is done on the specified blocks. The MISR values calculated by the hardware is compared to the values passed by the user, if they are not the same, then an error code is returned.
Prototype
UINT32 FlashArrayIntegrityCheck (PSSD_CONFIG pSSDConfig,
UINT32 lowEnabledBlocks,
UINT32 midEnabledBlocks,
UINT32 highEnabledBlocks,
UINT8 addrSeq,
MISR misrValue, void (*CallBack)(void));
Arguments
Argument
pSSDConfig lowEnabledBlocks midEnabledBlocks highEnabledBlocks
Table 42. Arguments for FlashArrayIntegrityCheck()
Description Range
Pointer to the SSD
Configuration Structure.
To select the array blocks in low address space for erasing.
To select the array blocks in mid address space for erasing.
To select the array blocks in high address space for erasing.
The values in this structure are chip-dependent.
Please refer to
for more details.
Bit-mapped value. Select the block in the low address space whose array integrity is to be evaluated by setting 1 to the appropriate bit of
lowEnabledBlocks. If there is not any block to be evaluated in the low address space,
lowEnabledBlocks must be set to 0.
Bit-mapped value. Select the block in the middle address space whose array integrity is to be evaluated by setting 1 to the appropriate bit of
midEnabledBlocks. If there is not any block to be evaluated in the middle address space,
midEnabledBlocks must be set to 0.
Bit-mapped value. Select the block in the high address space whose array integrity is to be evaluated by setting 1 to the appropriate bit of
highEnabledBlocks. If there is not any block to be evaluated in the high address space,
highEnabledBlocks must be set to 0.
28/41 DocID024388 Rev 3
UM1620 API specification
Table 42. Arguments for FlashArrayIntegrityCheck() (continued)
Argument Description Range
addrSeq misrValue
CallBack
To determine the address sequence to be used during array integrity checks.
The default sequence (addrSeq = 0) is meant to replicate sequences normal “user” code follows, and thoroughly check the read propagation paths.
This sequence is proprietary.
The alternative sequence (addrSeq = 1) is just logically sequential.
It should be noted that the time to run a sequential sequence is significantly shorter than the time to run the proprietary sequence.
A structure variable containing the MISR values calculated by the user using the off-line
MISR generation tool.
The individual MISR words can range from
0x00000000 - 0xFFFFFFFF
Address of void call back function pointer.
Any addressable void function address. To disable it use NULL_CALLBACK macro.
Return values
Type
UINT32
Table 43. Return values for FlashArrayIntegrityCheck()
Description Possible values
Successful completion or error value.
C90FL_OK
C90FL_ERROR_AIC_MISMATCH
C90FL_ERROR_AIC_NO_BLOCK
Troubleshooting
The trouble shooting given here comprises of hardware errors and input parameter error.
Table 44. Troubleshooting for FlashArrayIntegrityCheck()
Returned error bits Possible causes Solution
C90FL_ERROR_AIC_MISMATCH
C90FL_ERROR_AIC_NO_BLOCK
The MISR value calculated by the user is incorrect.
None of the Blocks are enabled for Array Integrity
Check
Re-calculate the MISR values using the correct Data and addrSeq.
The MISR calculated by the
Hardware is incorrect.
Hardware Error.
Enable any of the blocks using variables lowEnabledBlocks,
midEnabledBlocks and
highEnabledBlock.
Comments
The inputs lowEnabledBlocks, midEnabledBlocks and highEnabledBlocks are bit-mapped arguments that are used to select the blocks to be evaluated in the Low/Mid/High address
DocID024388 Rev 3 29/41
API specification UM1620
spaces of main array. The selection of the blocks of the main array is determined by setting/clearing the corresponding bit in lowEnabledBlocks, midEnabledBlocks or highEnabledBlocks.
The bit allocations for blocks in one address space are: bit 0 is assigned to block 0, bit 1 to block 1, etc. The following diagrams show the formats of lowEnabledBlocks, midEnabledBlocks and highEnabledBlocks for the C90FL module.
For low address space valid bits are from bit 0 to bit (lowBlockNum – 1). In which,
lowBlockNum
is the number of low blocks returned from FlashInit();
For middle address space valid bits are from bit 0 and bit (midBlockNum – 1). In which,
midBlockNum
is the number of middle blocks returned from FlashInit();
For high address space valid bits are from bit 0 to bit (highBlockNum – 1). In which,
highBlockNum
is the number of high blocks returned from FlashInit();
For example, below are bit allocations for blocks in Low/Mid/High Address Space of
SPC564A70:
Table 45. Bit allocation for blocks in low address space
MSB bit 31
reserved
…
…
bit 10
reserved
bit 9
block 9
bit 8
block 8
…
…
bit 1
block 1
LSB bit 0
block 0
MSB bit 31
reserved
Table 46. Bit allocation for blocks in middle address space
…
…
bit 4 bit 3 bit 2 bit 1
reserved reserved reserved block 1
LSB bit 0
block 0
MSB bit 31
reserved
Table 47. Bit Allocation for Blocks in High Address Space
…
…
bit 6
reserved
bit 5
block 5
bit 4
block 4
…
…
bit 1
Block 1
LSB bit 0
Block 0
If no blocks are enabled the C90FL_ERROR_AIC_NO_BLOCK error code is returned.
Depending on the address sequence specified the MISR values are calculated for the enabled blocks using the corresponding sequence. If the MISR values calculated by the hardware is not the same as the values passed to this API by the user then the API returns the error code C90FL_ERROR_AIC_MISMATCH
.
Assumptions
It assumes that the Flash block is initialized using a ‘FlashInit()’ API.
30/41 DocID024388 Rev 3
UM1620 API specification
2.7.2 FlashECCLogicCheck()
Description
This function checks the ECC logic of the Flash. The API simulates a single or double bit fault depending on the user input. If the simulated ECC error is not detected, then the error code C90FL_ERROR_ECC_LOGIC is returned.
Prototype
UINT32 FlashECCCLogicCheck (PSSD_CONFIG pSSDConfig,
UINT64 dataVal,
UINT64 errBits,
UINT32 eccValue)
Arguments
Argument
pSSDConfig dataValue errBits eccValue
Table 48. Arguments for FlashECCLogicCheck()
Description Range
Pointer to the SSD
Configuration Structure.
The values in this structure are chip-dependent.
Please refer to
for more details.
The 64 bits of data for which the ECC is calculated. The bits of dataValue are flipped to generate single or double bit faults.
Any 64-bit value.
Is a 64-bit mask of the bits at which the user intends to inject error.
Any 64-bit value, except zero.
It’s a 32 bit value which has to be passed by user. This is calculated ny using an offline ECC Calculator.
This is a corresponding ECC value for the data value passed by the user.
Note: Same data words should be used in off line
ECC calculator and Flash ECC logic check API.
Return values
Type
UINT32
Table 49. Return values for FlashECCLogicCheck()
Description Possible values
Successful completion or error value.
C90FL_OK
C90FL_ERROR_ECC_LOGIC
Troubleshooting
The trouble shooting given here comprises of hardware errors and input parameter error.
DocID024388 Rev 3 31/41
API specification UM1620
Table 50. Troubleshooting for FlashECCLogicCheck()
Returned error bits Possible causes Solution
C90FL_ERROR_ECC_LOGIC
The ECC value calculated by the user is incorrect.
Hardware Failure.
Re-calculate the ECC values using the correct Data.
Hardware error.
Comments
Depending on the errBits value, a single or double bit faults are simulated. When a Flash read is done, if the simulated error has not occurred, then the API returns the error code
C90FL_ERROR_ECC_LOGIC.
Assumptions
It assumes that the Flash block is initialized using a ‘FlashInit()’ API.
2.7.3 FactoryMarginReadCheck()
Description
This function checks the Factory Margin reads of the Flash. The user specified margin level is used for reads and the operation is done on the specified blocks. The MISR values calculated by the hardware is compared to the values passed by the user, if they are not the same, then an error code is returned.
Prototype
UINT32 FactoryMarginReadCheck (PSSD_CONFIG pSSDConfig,
UINT32 lowEnabledBlocks,
UINT32 midEnabledBlocks,
UINT32 highEnabledBlocks,
UINT8 marginLevel,
MISR misrValue, void (*CallBack)(void));
Arguments
Argument
pSSDConfig lowEnabledBlocks
Table 51. Arguments for FactoryMarginReadCheck()
Description Range
Pointer to the SSD
Configuration Structure.
The values in this structure are chip-dependent.
Please refer to
for more details.
To select the array blocks in low address space for erasing.
Bit-mapped value. Select the block in the low address space whose array integrity is to be evaluated by setting 1 to the appropriate bit of
lowEnabledBlocks. If there is not any block to be evaluated in the low address space,
lowEnabledBlocks must be set to 0.
32/41 DocID024388 Rev 3
UM1620 API specification
Table 51. Arguments for FactoryMarginReadCheck() (continued)
Argument Description Range
midEnabledBlocks highEnabledBlocks
To select the array blocks in mid address space for erasing.
Bit-mapped value. Select the block in the middle address space whose array integrity is to be evaluated by setting 1 to the appropriate bit of
midEnabledBlocks. If there is not any block to be evaluated in the middle address space,
midEnabledBlocks must be set to 0.
To select the array blocks in high address space for erasing.
Bit-mapped value. Select the block in the high address space whose array integrity is to be evaluated by setting 1 to the appropriate bit of
highEnabledBlocks. If there is not any block to be evaluated in the high address space,
highEnabledBlocks must be set to 0.
marginLevel
To determine the margin level to be used during factory margin read checks.
Selects the margin level that is being checked.
Margin can be checked to an erased level
(marginLevel=1) or to a programmed level
(marginLevel =0). misrValue
CallBack
A structure variable containing the MISR values calculated by the user using the offline
MISR generation tool.
The individual MISR words can range from
0x00000000 - 0xFFFFFFFF
Address of void call back function pointer.
Any addressable void function address. To disable it use NULL_CALLBACK macro.
Return values
Type
UINT32
Table 52. Return values for FactoryMarginReadCheck()
Description Possible values
Successful completion or error value.
C90FL_OK
C90FL_ERROR_FMR_MISMATCH
C90FL_ERROR_FMR_NO_BLOCK
Troubleshooting
The trouble shooting given here comprises of hardware errors and input parameter error.
DocID024388 Rev 3 33/41
API specification UM1620
Table 53. Troubleshooting for FactoryMarginReadCheck()
Returned error bits Possible causes Solution
C90FL_ERROR_FMR_MISMATCH
C90FL_ERROR_FMR_NO_BLOCK
The MISR value calculated by the user is incorrect.
Re-calculate the MISR values using the correct Data and address.
The MISR calculated by the Hardware is incorrect.
Hardware Error.
None of the Blocks are enabled for Factory
Margin Read Check
Enable any of the blocks using variables lowEnabledBlocks,
midEnabledBlocks and
highEnabledBlock.
Comments
The inputs lowEnabledBlocks, midEnabledBlocks and highEnabledBlocks are bit-mapped arguments that are used to select the blocks to be evaluated in the Low/Mid/High address spaces of main array. The selection of the blocks of the main array is determined by setting/clearing the corresponding bit in lowEnabledBlocks, midEnabledBlocks or highEnabledBlocks.
The bit allocations for blocks in one address space are: bit 0 is assigned to block 0, bit 1 to block 1, etc. The following diagrams show the formats of lowEnabledBlocks, midEnabledBlocks and highEnabledBlocks for the C90FL module.
For low address space valid bits are from bit 0 to bit (lowBlockNum – 1). In which, lowBlockNum is the number of low blocks returned from FlashInit();
For middle address space valid bits are from bit 0 and bit (midBlockNum – 1). In which, midBlockNum is the number of middle blocks returned from FlashInit();
For high address space valid bits are from bit 0 to bit (highBlockNum – 1). In which, highBlockNum is the number of high blocks returned from FlashInit();
For example, below are bit allocations for blocks in Low/Mid/High Address Space of
SPC564A70:
Table 54. Bit allocation for blocks in low address space
MSB bit 31
reserved …
… bit 10 bit 9
reserved block 9
bit 8
block 8 …
… bit 1
block 1
LSB bit 0
block 0
MSB bit 31
reserved
Table 55. Bit allocation for blocks in middle address space
…
…
bit 4 bit 3 bit 2 bit 1
reserved reserved reserved block 1
LSB bit 0
block 0
34/41 DocID024388 Rev 3
UM1620 API specification
MSB bit 31
reserved
Table 56. Bit allocation for blocks in high address space
…
…
bit 6
reserved
bit 5
block 5
bit 4
block 4
…
…
bit 1
Block 1
LSB bit 0
Block 0
If no blocks are enabled the C90FL_ERROR_FMR_NO_BLOCK error code is returned.
The MISR values are calculated for the enabled blocks using the logical sequence. If the
MISR values calculated by the hardware is not the same as the values passed to this API by the user then the API returns the error code C90FL_ERROR_FMR_MISMATCH.
Assumptions
It assumes that the Flash block is initialized using a ‘FlashInit()’ API.
DocID024388 Rev 3 35/41
CallBack timings
Appendix A CallBack timings
Note:
UM1620
Table 57. CallBack timings period for SPC564A70
API Name
Time (µs)
System clock = 40 MHz
FlashProgram() (size = 0x1000)
ProgramVerify() (size = 0x1000, CALLBACK_PV = 70)
FlashErase() (low block 0)
BlankCheck() (size = LOW_BLOCK0_SIZE, CALLBACK_BC = 80)
CheckSum (size = 0x1000, CALLBACK_CS = 120)
FlashArrayIntegrityCheck (low block 0)
FactoryMarginReadCheck (low block 0)
1.7
99.3
1.7
101.3
103.25
1.7
1.7
Callback time period for ‘CheckSum()’ is measured with CALLBACK_CS (CallBack function period for checksum)
Callback time period for ‘ProgramVerify()’ is measured with CALLBACK_PV (CallBack function period for program verify)
Callback time period for ‘BlankCheck()’ is measured with CALLBACK_BC (CallBack function period for program verify)
36/41 DocID024388 Rev 3
UM1620
Appendix B System requirements
System requirements
The C90FL SSD is designed to support a single C90FL Flash module embedded on microcontrollers. Before using this SSD on a different derivative microcontroller, user has to provide the information specific to the derivative through a configuration structure.
Tool name
CodeWarrior IDE
Diab PowerPC compiler
GreenHills
P/E
Table 58. System requirements
Description
Development tool
Compiler
Development tool
Debugger
Version number
2.7
5.7.0.0
6.1.4
DocID024388 Rev 3 37/41
Acronyms
Appendix C Acronyms
API
BIU
ECC
EVB
RWW
SSD
Abbreviation
Table 59. Acronyms
Complete name
Application Programming Interface
Bus Interface Unit
Error Correction Code
Evaluation Board
Read While Write
Standard Software Driver
UM1620
38/41 DocID024388 Rev 3
UM1620
Appendix D Document reference
Document reference
1.
SPC564A70B4, SPC564A70L7 32-bit MCU family built on the embedded Power
Architecture
®
(RM0068, Doc ID 18132)
DocID024388 Rev 3 39/41
Revision history
Revision history
UM1620
Date
18-Mar-2013
02-May-2013
18-Sep-2013
Table 60. Document revision history
Revision Changes
1
2
3
Initial release.
Removed
Table: CallBack timings period for SPC56EL60x,
SPC56XL70xx
Appendix D: Document reference
Updated Disclaimer.
40/41 DocID024388 Rev 3
UM1620
Please Read Carefully:
Information in this document is provided solely in connection with ST products. STMicroelectronics NV and its subsidiaries (“ST”) reserve the right to make changes, corrections, modifications or improvements, to this document, and the products and services described herein at any time, without notice.
All ST products are sold pursuant to ST’s terms and conditions of sale.
Purchasers are solely responsible for the choice, selection and use of the ST products and services described herein, and ST assumes no liability whatsoever relating to the choice, selection or use of the ST products and services described herein.
No license, express or implied, by estoppel or otherwise, to any intellectual property rights is granted under this document. If any part of this document refers to any third party products or services it shall not be deemed a license grant by ST for the use of such third party products or services, or any intellectual property contained therein or considered as a warranty covering the use in any manner whatsoever of such third party products or services or any intellectual property contained therein.
UNLESS OTHERWISE SET FORTH IN ST’S TERMS AND CONDITIONS OF SALE ST DISCLAIMS ANY EXPRESS OR IMPLIED
WARRANTY WITH RESPECT TO THE USE AND/OR SALE OF ST PRODUCTS INCLUDING WITHOUT LIMITATION IMPLIED
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE (AND THEIR EQUIVALENTS UNDER THE LAWS
OF ANY JURISDICTION), OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT.
ST PRODUCTS ARE NOT DESIGNED OR AUTHORIZED FOR USE IN: (A) SAFETY CRITICAL APPLICATIONS SUCH AS LIFE
SUPPORTING, ACTIVE IMPLANTED DEVICES OR SYSTEMS WITH PRODUCT FUNCTIONAL SAFETY REQUIREMENTS; (B)
AERONAUTIC APPLICATIONS; (C) AUTOMOTIVE APPLICATIONS OR ENVIRONMENTS, AND/OR (D) AEROSPACE APPLICATIONS
OR ENVIRONMENTS. WHERE ST PRODUCTS ARE NOT DESIGNED FOR SUCH USE, THE PURCHASER SHALL USE PRODUCTS AT
PURCHASER’S SOLE RISK, EVEN IF ST HAS BEEN INFORMED IN WRITING OF SUCH USAGE, UNLESS A PRODUCT IS
EXPRESSLY DESIGNATED BY ST AS BEING INTENDED FOR “AUTOMOTIVE, AUTOMOTIVE SAFETY OR MEDICAL” INDUSTRY
DOMAINS ACCORDING TO ST PRODUCT DESIGN SPECIFICATIONS. PRODUCTS FORMALLY ESCC, QML OR JAN QUALIFIED ARE
DEEMED SUITABLE FOR USE IN AEROSPACE BY THE CORRESPONDING GOVERNMENTAL AGENCY.
Resale of ST products with provisions different from the statements and/or technical features set forth in this document shall immediately void any warranty granted by ST for the ST product or service described herein and shall not create or extend in any manner whatsoever, any liability of ST.
ST and the ST logo are trademarks or registered trademarks of ST in various countries.
Information in this document supersedes and replaces all information previously supplied.
The ST logo is a registered trademark of STMicroelectronics. All other names are the property of their respective owners.
© 2013 STMicroelectronics - All rights reserved
STMicroelectronics group of companies
Australia - Belgium - Brazil - Canada - China - Czech Republic - Finland - France - Germany - Hong Kong - India - Israel - Italy - Japan -
Malaysia - Malta - Morocco - Philippines - Singapore - Spain - Sweden - Switzerland - United Kingdom - United States of America
www.st.com
DocID024388 Rev 3 41/41
Lataa
Mainos