In-circuit programming architecture with ROM and flash memory5901330Abstract An architecture for an integrated circuit with in-circuit programming includes a microcontroller on an integrated circuit and one or more banks of non-volatile memory which store instructions, including an in-circuit programming (ICP) set of instructions. Using a control program stored on the device, the device interactively establishes an in-circuit programming exchange with a device external to the integrated circuit and uses data obtained in the exchange to update software for the microcontroller. Portions of the ICP code which are likely to change between different application environments are stored in reprogrammable flash memory cells. Other portions of the ICP code, which are not likely to change between different application environments, are stored in space-efficient mask ROM memory cells. In this way, the ICP system can be flexibly adapted to different application environments, while conserving on silicon area occupied the ICP system. Claims What is claimed is: Description COPYRIGHT NOTICE PURSUANT TO 37 C.F.R. 1.71(E)
TABLE 1
______________________________________
.COPYRGT. 1996 Macronix International, Co., Ltd.
FMCON: Flash Module Control register
FMCON›7:4!: Reserved
FMCON›3:0!: i.e. MS›3:0! of MTPG2 module
normal read MTP module at DPTRIPA›15:0!
location;
this is the default value after
reset:
0001: erase 0-64KB as well as LOCK bits
0010: block erase; erase 0-16K if DPTR ›2:0! = 000
erase 16-32K if DPTR ›2:0! = 010
erase 32-48K if DPTR ›2:0! = 100
erase 48-56K If DPTR ›2:0! = 110
erase 56-64K if DPTR ›2:0! = 111
0011:
program byte at DPTR/PA ›15:0! with data =
FMDATA/DQ›7:0!
0100: verify erased byte at DPTR/PA ›15:0!
0101: verify programmed byte at DPTR/PA ›15:0!
program lock
0110: bits, program LOCK›1! to be 1 if DPTR ›1:0! = 00
program LOCK›2! to be 1 if
DPTR ›1:0! = 01
program LOCK›3! to be I if
DPTR ›1:0! = 1x
verify three programmed lock bits
1001: erase status bits as well as boot vector
1010: program status bits or boot vector;
program SBIT›1:0! if DPTR›0! = 0 with
FMDATA/DQ›1:0!
program BVEC›7:0! if DPTR›0! = 1 with
FMDATA/DQ›7:0!
verify programmed status bits or boot vector;
verify SBIT›1:0! if DPTR›0! = 0
verify BVEC›7:0! if DPTR›0! = 1
read Manufacture ID or Device ID
______________________________________
Table 2 contains a listing of the functions implemented by various bits within timing register 154. By manipulating these bits, microcontroller 100 produces the wave forms required for flash memory erase, program, verify and read operations.
TABLE 2
______________________________________
FMTIM: Flash Module Timing register, used by software to
emulate the
waveform needed for flash operations.
FMTIM›7!: VPP Enable bit.
FMTIM›6!: Module Enable bit
FMTIM›5!: Read Enable bit
FMTIM›4!: Write Enabie bit
FMTIM›3:0!: Reserved
______________________________________
Mask ROM module 160 contains code to implement erase, program and verify handler 162. This includes code to perform the sequencing and timing of the erasing, programming and verifying operations involved in-circuit programming. A listing of this type of code for a preferred embodiment of the present invention appears in Table 3. Table 3 is an 8051 assembly code listing of subroutines involved in the erasing, programming and verifying functions of the in-circuit programming system.
TABLE 3
__________________________________________________________________________
;.COPYRGT. 1996 Macronix International Co., Ltd.
; SFR define
.EQU FMCON, 0x40H ; Flash Module CONtrol register
.EQU FMTIM, 0x41H
; Flash Module TIMing
register
; used
by s/w to emulate the emulate
; the
waveform needed for flash
operations
.EQU delay1, 0xFAH
; Tck 1/Fosc (ns)
; delayl =
(256 - 2000/(Tck*12) + 1)
; delay2 =
(500000000/(Tck* 12 *
.EQU delay2, 0x1AH
65536)
; Subroutine: Erase full chip
ERASE:
MOV FMCON, #00010010b
; chip erase
MOV FMTIM, #11000000b
; VPP in and CEB is active
LCALL DELAY2us ; delay tVPS or tCES
(2us)
MOV FMTIM, #1l0l0000b
; WEB is active
LCALL DELAY1s ; delay tEW (erase time)
MOV FMTIM, #11000000b
; disable WEB
LCALL DELAY500ms
; delay tER (0.5s)
MOV FMTIM, #00000000b
; clear FMTIM
MOV FMCON, #00000000b
; clear FMCON
RET
; Subroutine: Verify erased byte
ERASE.sub.-- VERIFY:
MOV FMCON, #00010010b
; verify chip erase
MOV FMTIM, #1l000000b
; VPP in, CEB is active
MOV DFTR, #00H
; Address
LCALL DELAY2us ; delay tMS (2us)
MOV FMTIM, #11100000b
; OEB is active
MOV R1, #00H
MOV R0, #00H
NOP
NOP
LOOP.sub.-- E:
; MOVX A,@DPTR ; read Flash
CJNE A,#0xFFR, ERASE.sub.-- FAIL
INC DPTR
DJNZ R0, LOOP.sub.-- E
DJNZ R1, LOOPE
MOV R7, #0xFFH
; erase verify passed
SJMP END.sub.-- EV
ERASE.sub.-- FAIL:
MOV R7,A ; erase verify fail
END.sub.-- EV:
MOV FMTIM, #0000000b
; clear FMTIM
MOV FMCON, #0000000b
; clear FMCON
RET
; Subroutine: Program byte
; DPTR: program address
; A: program data
PROGRAM.sub.-- B:
MOV FMCON, #00010001b
; program byte
LCALL PROGRAM
MOV FMCON, #00000000b
; clear FMCON
RET
; Subroutine Verify Byte
; DPTR: verify address
; A: verify data
VERIFY.sub.-- B:
MOV FMCON, #00010011b
; verify byte
MOV FMTIM, #110000000b
; VPP in, CEB active
MOV B, A
LCALL DELAY2us ; delay tPV(2us)
MOV FMTIM, #111l00000b
; OEB is active
NOP ; delay 4 NOP
NOP
NOP
NOP
CJNE A, B, VERIFY.sub.-- B.sub.-- FAIL
MOV R7, #0xFFH
; verify passed
SJMP END.sub.-- PV
VERIFY.sub.-- B.sub.-- FAIL
MOV R7, A ; program verify fail
END.sub.-- PV:
MOV FMTIM, #00000000b
; clear FMTIM
MOV FMCON, #00000000b
; clear FMCON
RET
; Subroutine: Program LOCK bits
; which lock bit being programmed depends on DPTR ›2:0!
PROGRAM.sub.-- L:
MOV FMCON, #00010100b
; program LOCK bit
LCALL PROGRAM
MOV FMCON, #00000000b
; clear FMCON
RET
; Subroutine: Verify LOCK bits
VERIFY.sub.-- L:
MOV FMCON, #00010101b
; verify three programmed lock bits
LCALL VERIFY.sub.-- L.sub.-- S
MOV FMCON, #00000000b
; clear FMCON
RET
; Subroutine: Program Status bit
PROGRAM.sub.-- S:
MOV FMCON, #00010110b
; program State bit
LCALL PROGRAM
MOV FMCON, #00000000b
; clear FMCON
RET
; Subroutine: Verify programmed status bit
VERIFY.sub.-- S:
MOV FMCON, #00010111b
; verify state bit
LCALL VERIFY.sub.-- L.sub.-- S
MOV FMCON, #00000000b
; clear FMCON
RET
; Subroutine: PROGRAM
PROGRAM:
MOV FMTIM, #11000000b
; VPP in, CEB active
LCALL DELAY2us ; delay tVPS or tCES or
tMS (2us)
MOV FMTIM, #11010000b
; WEB is active
LCALL DELAY100us ; delay tPW(100us)
MOV FMTIM, #11000000b
; disable WEB
LCALL DELAY2us ; delay tPR (2us)
MOV FMTIM, #00000000b
; clear FMTIM
RET
; Subroutine: Verify LOCK bits or State bit
VERIFY.sub.-- L S:
MOV B, A
MOV FMTIM, #01000000b
; VPP = 5V, CEB active
LCALL DELAY2us ; delay tVPS or tCES
or tMS (2us)
MOV FMTIM, #11100000b
; OEB is active
NOP
NOP
NOP
NOP
CJNE A, B, VERIFY.sub.-- LS.sub.-- FAIL
MOV R7, #0xFFH
; verify LOCK or State
bit passed
SJMP END.sub.-- VLS
VERIFY.sub.-- LS.sub.-- FAIL
:
MOV R7, A ; verify LOCK or state fail
END.sub.-- VLS:
MOV FMTIM, #00000000b
; clear FMTIM
RET
; Subroutine: DELAY2us
DELAY2us:
PUSH IE
EA
TH1, #0xFFH
MOV
TL1, #delay1
MOV
TCON, #00H
MOV
TMOD, #10H
; TIMER1, MODE 1
SETB
TR1 ; start TIMER1
LOOP1:
JNB TF1,LOOP1
TCON, #00H
; clear TF1 and TR1
POP
IE
RET
; Subroutine: DELAY100us
DELAY100us
MOV R7, #0x32H
LOOP2:
LCALL
DELAY2us
DJNZ R7, LOOP2
RET
; Subroutine: DELAY500ms
DELAY500ms:
PUSH IE
EA
R7, #delay2
TCON, #00H
MOV
TMOD, #10H
; TIMER1, MODE 1
LOOP4:
MOV TH1, #00H
MOV
TL1, #00H
SETB
TR1
LOOP3:
JNB TF1, LOOP3
MOV
TCON, #00H
; clear TF1 and TR1
DJNZ
R7, LOOP4
POP IE
RET
; Subroutine: DELAY1s
DELAY1s:
LCALL DELAY500ms
LCALL DELAY500ms
RET
.END
__________________________________________________________________________
The key insight behind the present invention is that the in-circuit programming code can be divided into two pieces. Portions of the code which are commonly modified, such as the in circuit programming communication handler, which must be reconfigured for each different communication protocol, are stored in flash memory within multiple time programming module 140. Portions of the ICP code which do not have to be modified, specifically erase, program and verify functions which are specifically tailored to the architecture of multiple time programming module 140, are stored in space-efficient mask ROM module 160. Referring to FIG. 1, the in-circuit programming process operates as follows: microcontroller 100 executes code from ICP communication handler 142, which communicates with an ICP initiator at a remote site across one of I/O ports 120. New instructions to be loaded into the user code section 144 of multiple time programming module 140 are transferred through one of I/O ports 120 into microcontroller 100. Microcontroller 100 executes code in erase/program/verify handler 162 within mask ROM module 160 which loads the new code into user code section 144 of multiple time programming module 140. Microcontroller 100 operates in conjunction with watchdog timer 110, which is used to detect deadlocks in microcontroller 100's execution of the in-circuit programming code. In order to program the new instructions into multiple time programming module 140, microcontroller 100 first erases a portion of multiple time programming module 140 through a sequence of instructions written into control register 152 and timing register 154. Microcontroller 100 then programs the new code into multiple time programming module 140 through additional instructions written into control register 152 and timing register 154. Finally, microcontroller 100 verifies the programming of the new code in multiple time programming module 140 through a sequence of instructions written to control register 152 and timing register 154. FIG. 2 illustrates the address space 200 viewed by microcontroller 100. This address space is divided into a plurality of independently erasable blocks of flash memory as well as a block of mask ROM memory. User block #1 260 extends from address 0 to address 16K. User block #2 250 extends from address 16K to address 32K. User block #3 240 extends from address 32K to address 48K. User block #4 230 extends from address 48K to address 56K. Primary boot code for downloading new user codes 220 is located between addresses 56K and 63K. This primary boot code is used during system boot up for downloading new instructions into user code section 144 of multiple time programming module 140. If this primary boot code space is insufficient, user block #4 230 may be used to store secondary boot code. The address space between 63K and 64K contains erase/program/verify subroutines 210. This portion of address space 200 is located within mask ROM module 160. The other portion of address space 200 from 0 to 63K is located in flash memory cells in multiple time programming module 140. Although these two portions of address space 200 reside within different memory modules, they comprise portions of a single address space 200 for microcontroller 100. Instructions from mask ROM module 160 and multiple time programming module 140 are selectively switched into microcontroller 100 through MUX 130. In the embodiment illustrated in FIG. 1, only a single mask ROM module 160 and a single multiple time programming module 140 are illustrated. Alternative systems include more than one mask ROM module and more than one module of flash memory cells, allowing even greater flexibility in the design and implementation of in-circuit programming instructions. FIG. 3 illustrates the application environment for the present invention The invention is implemented on an integrated circuit 310, which is placed within system 300; system 300 comprises either a printed circuit board or some other system implementation. Integrated circuit 310 includes microcontroller 100, mask ROM module 160, and multiple time programming module 140 as well as the other components of the ICP system illustrated in FIG. 1. Microcontroller 100 is coupled to a plurality of integrated circuits (ICs) 312, 314 and 316. Bridge to communication channel 320 provides a channel across which in-circuit programming code is transferred. Bridge to communication channel 320 may comprise a simple network port, or may include extra glue logic to make the ICP system transparent to non-ICP code. The functionality of bridge to communication channel 320 can be modified, allowing bridge to communication channel 320 to be coupled to diverse ICP communication channels having different levels of data rates, error rates and complexity. For example, in one embodiment communication channel 330, comprises an Internet executing an Internet communication protocol. Bridge to communication channel 320 is coupled through communication channel 330 to an ICP initiator 340, such as a personal computer or workstation. ICP initiator 340 is coupled by a communication channel 345 to large scale storage device 350. ICP initiator 340 can be coupled to microcontroller 100 in a variety of ways. In one embodiment, an ICP initiator 340 is a world wide web site accessed through the Internet on communication channel 330. Alternatively, ICP initiator 340 acts as the initiator across a dial-up modem link. In yet another embodiment, communication channel 330 is a communication bus in a personal computer system, and the in-circuit software is loaded across the bus 330. In this embodiment, upgrades to system 300 can be distributed to end users on floppy disks or otherwise loaded through ICP initiator 340. In some applications, bridge to communication channel 320 is not required. Referring to FIG. 1, in some applications the software contained within ICP communication handler 142 is sufficient by itself to implement the proper protocol for ICP communications through one of I/O ports 120 across communication channel 330. This allows one of I/O ports 120 to directly connect to communication channel 330, thereby eliminating the need for bridge to communication channel 320. FIGS. 4A, 4B and 4C contain a flowchart of the operations involved in the in-circuit programming process. Each of the FIGS. 4A, 4B and 4C are divided into four columns. The first column, labeled "ICP Initiator 340," represents the activities of in-circuit programming initiator 340, which is illustrated in FIG. 3. ICP initiator 340 is a device external to integrated circuit 310 which is connected to in-circuit programming systems 300 through a communication channel 330. ICP initiator 340 initiates and controls the in circuit programming process. The remaining three columns of FIGS. 4A, 4B and 4C represent actions of microcontroller 100 in executing different bodies of code stored within mask ROM module 160 and multiple time programming module 140. The column labeled "user code 144" represents activities of microcontroller 100 while executing user code 144 within multiple time programming module 140. The column labeled "ICP communication handler 142" represents the actions of microcontroller 100 while executing ICP communication handler 142 within multiple time programming module 140. The column labeled "erase/program/verify handler 162" represents the actions of microcontroller 100 while executing erase/program/verify handler 162 within mask ROM module 160. The in-circuit programming process as illustrated in FIGS. 4A, 4B and 4C operates as follows. Upon system reset or when watchdog timer 110 times out, microcontroller 110 enters state 430 wherein a status bit is checked. If the status bit is zero, microcontroller 100 enters step 420 within user code 144. If the status bit is set to a one, microcontroller 100 jumps to the location pointed to by the boot vector and executes step 440 within ICP communication handler 142. At step 420, microcontroller 100 waits to get the next command from ICP initiator 340. When ICP initiator 340 executes step 400, it transmits an update command to microcontroller 100. This update command is received by microcontroller 100, causing it to proceed to step 421. Step 421, microcontroller 100 asks whether the command received was an update command. If not, microcontroller 100 proceeds to step 426, in which normal operation of microcontroller 100 takes place, and microcontroller 100 executes non-ICP user code. The system then returns to step 420 to get the next command. If the command was an update command, microcontroller 100 proceeds to step 422, in which a "request to confirm" is sent to ICP initiator 340. After executing step 400, ICP initiator 340 proceeds to step 401 in which ICP initiator 340 waits for a request to confirm. When the request to confirm command is received, ICP initiator 340 proceeds to step 402, in which a confirm command is transmitted to microcontroller 100. Microcontroller 100 receives this confirm command at step 423, and proceeds to step 445 within ICP communication handler 142, in which microcontroller 100 transmits a ready to ICP command to ICP initiator 340. After issuing the confirm command, ICP initiator 340 proceeds to step 403, where ICP initiator 340 waits for a ready to ICP command from microcontroller 100. If at step 430, the status bit was set to one, microcontroller 100 executes a set of steps to confirm the ICP request within ICP communication handler 142. These steps almost precisely mirror the steps used to confirm the ICP request within user code 144 when the status bit was set to zero. At step 440, microcontroller 100 waits for the next command from ICP initiator 340. When ICP initiator 340 executes step 400, it transmits an update command to microcontroller 100. When this update command is received by microcontroller 100 at step 440, microcontroller 100 proceeds to step 441 in which microcontroller 100 determines whether the command was an update command. If not, microcontroller 100 proceeds to step 442 in which no operation (a NOOP) takes place. Microcontroller 100 then returns to step 440 to receive another command. If microcontroller 100 received an update command at step 441, it proceeds to step 443 in which microcontroller 100 transmits a request to confirm command to ICP initiator 340. After ICP initiator 340 executes step 400, it proceeds to step 401 where it waits for a request to confirm command. Upon receiving the request to confirm command from microcontroller 100, ICP initiator 340 proceeds to step 402 where it transmits a confirm command to microcontroller 100. After executing step 443, microcontroller 100 proceeds to step 444 where it waits for the confirm command from ICP initiator 340. Upon receiving the confirm command, microcontroller 100 proceeds to step 445 in which microcontroller 100 transmits a "ready to ICP" command to the ICP initiator 340. After executing step 402, ICP initiator 340 proceeds to step 403, where it waits for a ready to ICP command from microcontroller 100. At this point, the confirmation process for the ICP command is complete and the downloading of the new user code takes place. After executing step 403, ICP initiator 340 proceeds to step 404, wherein ICP initiator 340 downloads the new user code in encrypted format across communication channel 330 to microcontroller 100. At step 446, microcontroller 100 receives the new user code, and decrypts the data format. After executing 446, microcontroller 100 proceeds to step 447, in which it sends a checksum to ICP initiator 340. After executing 404, ICP initiator 340 proceeds to step 405 where it waits for the checksum. After receiving the checksum, ICP initiator 340 proceeds to step 406 in which it verifies whether the checksum matches the checksum of the code that was sent to microcontroller 100. If the checksum does not match, ICP initiator 340 proceeds to step 408, which is an end state, and an error is flagged. If the checksum matches, ICP initiator 340 proceeds to step 407 in which it issues a go ahead command. After sending the checksum at step 447, microcontroller 100 proceeds to step 448 in which it waits for the go ahead command. Upon receiving the go ahead command from ICP initiator 340, microcontroller 100 proceeds to step 449 in which the in-circuit programming commences. At step 449, microcontroller 100 programs and verifies the boot vector and sets the status bit to 1 indicating that an ICP operation is taking place. Microcontroller 100 then verifies that the status bit is set, and proceeds to set and start watchdog timer 110. Microcontroller 100 then proceeds to step 450 in which it calls the erase subroutine from erase/program/verify handler 162. Microcontroller 100 then proceeds to step 460 in erase/program/verify handler 162, in which microcontroller 100 erases the specified blocks within multiple time programming module 140. Microcontroller 100 then proceeds to step 451 within ICP communication handler 142. At step 451, microcontroller 100 calls the verify byte subroutine from erase/program/verify handler 162. Microcontroller then proceeds to step 461 in which the verify byte subroutine is executed. Microcontroller 100 then proceeds to step 452 within ICP communication handler 142. At step 452, microcontroller 100 determines whether or not the verification of the erase operation is complete. If not, microcontroller 100 returns to step 451 to verify the subsequent byte. If so, microcontroller 100 proceeds to step 453 in which microcontroller 100 transmits an erase OK command to ICP initiator 340. After executing step 407, ICP initiator 340 proceeds to step 409 in which ICP initiator 340 waits for an erase OK command. After receiving the erase OK command, ICP initiator 340 proceeds to step 410 where ICP initiator 340 waits for a program OK command from microcontroller 100. After issuing the erase OK command at step 453, microcontroller 100 proceeds to step 454 in which microcontroller 100 calls the program byte subroutine from erase/program/verify handler 162. Microcontroller 100 then proceed to step 462 in which the program byte subroutine is executed. Microcontroller 100 next advances to step 455 within ICP communication handler 142. At step 455, microcontroller 100 determines whether the programming is finished. If not, microcontroller 100 returns to step 454 to call the program byte command for the subsequent byte to be programmed. If the programming is complete, microcontroller 100 proceeds to step 456 in which the verify byte subroutine is called. Microcontroller 100 then proceeds to the verify byte subroutine at step 463 within erase/program/verify handler 162. At step 463, the verify byte subroutine is executed. Microcontroller 100 then proceeds to step 457 within ICP communication handler 142. At step 457, microcontroller 100 determines whether the verify operation is complete. If not, microcontroller 100 returns to step 456, where the verify byte subroutine is called for a subsequent byte to be verified. If the verification operation is complete, microcontroller 100 proceeds to step 458. At step 458, the erase, program and verify operations for the in-circuit programming are complete. Microcontroller 100 sets the status bit to 0 and verifies that it is set to 0. It then turns off watchdog timer 110. Microcontroller 100 then proceeds to step 459 in which it issues a program OK command to ICP initiator 340. ICP initiator 340 receives the program OK command at step 410 and proceeds to step 411 in which ICP initiator 340 transmits a reset command to microcontroller 100. After issuing the program OK command at step 459, microcontroller 100 proceeds to step 424 within user code 144 in which it waits for a reset command. When a reset command is received from ICP initiator 340, microcontroller 100 proceeds to step 425 which is an end state. After issuing the reset command at step 411, ICP initiator 340 proceeds to step 412 which is also an end state. At this point the in-circuit programming process is complete. This process will be repeated when a new in-circuit programming process is initiated by ICP initiator 340. Using the architecture illustrated in FIG. 1, designers of systems can adapt the in-circuit programming code to their particular environment. Thus, a manufacturer selects an integrated circuit, as shown in FIG. 1, for implementation in their circuit. If the in-circuit programming code is not ready, microcontroller 100 is utilized and the variety of communication ports available on the chip 300 are used to minimize the extra logic required on the circuit board to match the system to a particular in-circuit programming environment. First, the proper connections and protocol for in-circuit programming are selected by the designer. Next, the ICP code for the selected environment is developed and improved. The ICP code is then integrated with the programs to be executed during normal operation of the system. Next, the integrated ICP code and user code are stored in the flash memory of multiple time programming module 140. Then, the erase and program operations are verified. Microcontroller 110, including the integrated ICP code, is then placed inside the system. Next, the ICP code is executed and tested. If the system works well, the system is mass produced. If the ICP code needs modification, then the ICP process is repeated to optimize the ICP code. Similarly, the system code is optimized using the same programming techniques. The end user of the system thus obtains robust in-circuit programming code embedded in microcontroller 100, which can be updated and modified on the fly using the interactive in-circuit programming techniques according to the present invention. CONCLUSION Accordingly, the present invention provides a flexible flash memory-based microcontroller architecture which allows for diverse in-circuit programming applications. For example, televisions or video monitors, digital video disks or CD-ROMs, remote control devices or mobile telephones may include microcontrollers with in-circuit programming structures according to the present invention. Various sources of updated ICP code can then be loaded into respective devices using the flexible architecture of the present invention. The present invention can be thereby modified or adapted for a particular application environment. Very little or no glue logic is required in order to support the in-circuit programming structures. Furthermore, the power of the microcontroller associated with the in-circuit programming can be leveraged to simplify the design of flash memory for the in-circuit programming system. Silicon real estate on the integrated circuit is conserved by storing integrated circuit-specific portions of the ICP code, which are not likely to change, in space efficient mask ROM cells. Other parts of the ICP code, such as the communication handler, which are likely to be modified frequently are maintained in flash memory. In this way, silicon real estate can be saved while maintaining the flexibility to tailor the in-circuit programming system for a wide variety of different applications. The foregoing description of the preferred embodiment of the invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Obviously, many modifications and variations will be apparent to practitioners skilled in this art. It is intended that the scope of the invention be defined by the following claims and their equivalents.
|
Same subclass Same class Consider this |
||||||||||
