1<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
2<HTML>
3<HEAD>
4<META http-equiv="Content-Type" content="text/html; charset=windows-1252">
5<META name="GENERATOR" content="IBM WebSphere Studio Homepage Builder Version 7.0.0.0 for Windows">
6<META http-equiv="Content-Style-Type" content="text/css">
7<TITLE>Backup Access: Overview</TITLE>
8<LINK rel="stylesheet" href="../../css/nitro.css" type="text/css">
9</HEAD>
10<BODY>
11<H1 align="left">Backup Access: Overview</H1>
12<H2>Description</H2>
13<P>The backup device is connected to the SPI bus in a Nintendo DS card. By conducting serial communications of commands through the IO register, operations such as state checks and data transfer are performed. The type and limitations of the commands prepared depend on the device type and size, but there are features as listed below that are generally shared.<br>
14<ul>
15<li>All empty memory is divided depending on specific page sizes, and each page waits individually for the write count lifespan.
16<li>If a write-related command is generated, the device goes into a busy state until it finishes.
17<li>The amount of time it's in a busy state is proportionally longer than the write count accumulation, and it will never end within the given period of time.
18<li>This does not depend on the write count and there is also a period of data maintenance for the whole device.
19</ul>
20</P>
21<HR>
22<P><B>Device Types</B></P>
23<P>The following are the main backup device types and their features supported by the current CARD library.</P>
24<table>
25<tr><td>Device Types</td><td>Features</td></tr>
26<tr><td>EEPROM</td><td>Standard feature, a relatively small amount of memory.</td></tr>
27<tr><td>FLASH</td><td>Memory with large capacity but comparatively slow writing speed.<br />For particularly large-capacity flash memory devices, the process of rewriting data can be somewhat complicated. &nbsp;</td></tr>
28</table>
29<P><br>There is no way to automatically determine which type of backup device is loaded in the DS Card, so an application needs to be aware of the device type that it will use and explicitly specify it with the <A href="../common/CARD_IdentifyBackup.html"><CODE>CARD_IdentifyBackup</CODE></a> function before any function call to backup access functions. You must make sure that ROM header information is determined in advance, as indicated in the guidelines, to prevent problems such as data being destroyed by carelessly accessing a DS card that has not been defined in detail. This is especially important for applications that will be executed by something other than the DS card, as in Single-Card Play. Under those conditions, restrictions in the CARD library are applied automatically, and the card cannot be accessed as long as the <A href="../common/CARD_Enable.html"><CODE>CARD_Enable</CODE></a> function is not called. The ROM header information for the inserted DS Card can be referenced with the <A href="../common/CARD_GetRomHeader.html"><CODE>CARD_GetRomHeader</CODE></a> function.<br><br />As mentioned above, different types of flash devices can use different types of commands and have different restrictions. In particular, the <CODE>Write</CODE> command that performs a simple rewrite operation cannot be used with flash memory devices above a certain capacity. To perform a rewrite operation on such devices, you must use a combination of the <CODE>EraseSector</CODE> operation to erase data at the sector level, and the <CODE>Program</CODE> operation to write data to sectors after they have been erased. <br />The table below lists currently supported devices and their operating characteristics.</P>
30<table>
31<tr><td style="text-align:center">Device Types</td><td style="text-align:center" colspan="3">EEPROM</td><td style="text-align:center" colspan="5">FLASH</td></tr>
32<tr><td>Size</td><td>4 KB</td><td>64 KB</td><td>512 KB</td><td>2 MB</td><td>4 MB</td><td>8 MB</td><td>16 MB</td><td>64 MB</td></tr>
33<tr><td>Page Size</td><td style="text-align:center" colspan="3"><font color="gray">(Total Capacity)</font></td><td style="text-align:center" colspan="5">256 B</td></tr>
34<tr><td>Sector Size</td><td style="text-align:center" colspan="3"><font color="gray">(Total Capacity)</font></td><td style="text-align:center" colspan="5">65536 B</td></tr>
35<tr><td>Write (a direct write operation that does not require erasing)</td><td style="text-align:center" colspan="3">O</td><td style="text-align:center" colspan="4">O</td><td style="text-align:center;background-color:#FFC0C0" colspan="1">X</td></tr>
36<tr><td>Program (a write operation that takes place after erasures)</td><td style="text-align:center" colspan="3">X</td><td style="text-align:center" colspan="5">O</td></tr>
37<tr><td>EraseSector (the sector-erase operation)</td><td style="text-align:center" colspan="3">X</td><td style="text-align:center" colspan="5">O</td></tr>
38</table>
39
40
41<HR>
42<P><B>Flow of Access functions</B></P>
43<P>This is an explanation of the flow of operations after backup access functions are called.</P>
44<BLOCKQUOTE><IMG src="image_BackupAccess.gif" border="0"></BLOCKQUOTE>
45<ol>
46<li>Most device commands related to data transfer are limited to a unique size by pages or sectors, so the CARD library automatically divides content specified by the user into several appropriately sized commands.
47<li>Each divided command is executed in order. Command execution and the busy determination that follows need to be managed from beginning to end directly by the CPU, so this operation is mounted by a relatively low-priority thread on the ARM7 component side. Command execution requests are sent one at a time from ARM9 through PXI.
48<li>When the command is finished in ARM7, ARM9 is notified of the result in the same way through PXI.
49<li>If there are any remaining divided commands, command execution request is sent from ARM9 again at this point. This is repeated until processing is complete, ends in failure, or has been canceled by the <a href="../backup/CARD_CancelBackupAsync.html"><CODE>CARD_CancelBackupAsync</CODE></a> function. Because things such as memory copy in the operations to wait for completion and a new execution request sometimes take a long time, they are mounted by an internal thread in the CARD library instead of with the PXI interrupt handler.
50<li>When the operation is complete, a notification is sent to the source of the specified callback. The processing result can be referenced with the <a href="../common/CARD_GetResultCode.html"><CODE>CARD_GetResultCode</CODE></a> function as a <a href="../card_result_const.html"><CODE>CARDResult</CODE></a> enumerated type.
51</ol>
52<P>
53<H2>See Also</H2>
54<P><A href="../list_card.html">CARD Function List</A></P>
55<H2>Revision History</H2>
56<P>
572008/11/27 Deleted <CODE>CARD_BACKUP_TYPE_FRAM_256KBITS</CODE> from the lineup of usable types.<br> 2007/08/22 Added explanation about large-capacity flash devices and a table showing their characteristics.<br> 2006/01/01 Initial version.
58</P>
59<hr><p>CONFIDENTIAL</p></body>
60</HTML>