Modem with firmware upgrade feature6928108Abstract Updated operating code and parameters can be reprogrammed into a modem system with no disassembly of the modem hardware. The modem system includes a memory chip in which operating code and parameters are stored. Two control programs control the reprogramming of updated operating code. One of the control programs is designed for manufacturing and testing purposes. The other control program allows remote reprogramming of updated operating code or parameters from a remote location such as a customer site. A user can thus remotely upgrade system firmware with updates, bug fixes, enhancements or other new releases of system operating code by downloading the update over a phone line to a host PC and reprogramming the memory chip of the modem over the serial port from the host PC. The user can also remotely upgrade the modem system firmware by directly programming the memory chip of the modem without the assistance of the host PC. The modem system is portable, obtaining power from a standard 9 volt battery. Therefore, various power saving features are also incorporated into the modem system. Claims 1. An apparatus comprising: Description FIELD OF THE INVENTION
FIG. 8A shows a detailed flow diagram of the flash control program 800. The beginning of the flash control program 800 is shown. First, the internal environment and variables are initialized. The preferred flash control program 800 accepts either command line parameters or can be run in a menu driven mode. The present state of the user interface screen is saved and cleared while the field upgrade control program is running. The screen is saved for later restoration after the reprogramming is completed. Flash control program 800 continues at control block 802, which starts the help system. The help system reports onscreen status messages to the user during various stages of reprogramming. At times information may be requested from the user. Also, error messages and possible courses of action are displayed when appropriate. Next, flash control program 800 reads the setup file to determine which serial port the modem is connected through, the appropriate baud rate and other necessary setup information. The serial port is then initialized according to the setup information obtained. Control block 804 allocates a 128 kbyte memory buffer in the host PC. This memory buffer is used to store processed HEX files containing the updated operating code to be programmed into the flash PROM in the modem. Processing of the HEX files is described in detail below with respect to FIG. 8B. If "AUTOMATIC MODE" is set at query 806, flash control program 800 automatically runs the user through the reprogramming procedure. However for certain manufacturing and R&D purposes, it is desirable for the user to have more control over the reprogramming procedure. Thus, automatic mode can be disabled. When automatic mode is disabled, the flash control program checks whether the name of the HEX file to be programmed is present on the command line. If not, a user "PROCESS MENU" will appear on the screen at control block 807 with the choices "PORT SETUP," "READ FILE," "PROGRAM," or "EXIT." The user can then select the functions to be performed. If the HEX file name was on the command line, the flash control program continues with READ AND PROCESS FILE routine 810 described in detail below. Otherwise, in AUTOMATIC MODE, flash control program 800 continues at the top right portion of FIG. 8A with control block 808. Here all HEX files present in the host PC are found and their names displayed onscreen. The user chooses the name of the file to be programmed into the modem. If the desired file is not listed, the user can press the ESC key to exit the program. Although the bytes of each record in the HEX files downloaded from the bulletin board are sequential, the HEX records themselves are in no particular order within the file. The file must therefore be processed and sorted into a format which can be programmed into the modem. READ AND PROCESS FILE routine 810 reads the standard Intel HEX files stored in the host PC and performs the necessary HEX file processing. FIG. 8B shows a detailed flow diagram of the READ AND PROCESS FILE routine 810. The purpose of READ AND PROCESS FILE routine 810 is to convert the ASCII HEX characters contained in the HEX records to a binary format appropriate for programming into flash PROM U7. Routine 810 begins with an update of the onscreen help display. Next, the memory buffer is "zapped", i.e., set to all FF hex (all 1 binary). This corresponds to the erased state of flash PROM U7. Next the HEX file is opened for read access and the first HEX record is read. The record is then parsed to check syntax and to determine the record type indicated by the record type field of each HEX record as described above. If the record is type 0 the record is a data record. The record is processed as a data to be loaded in the memory buffer at the current memory pointer, where the pointer is the current 64 k page plus the address supplied in the record. After the data is converted from a ASCII text to binary and stored to the memory buffer, the pointer is incremented to the next available space in the buffer. Record type 02 indicates an extended address record. The information in these records is converted from ASCII text to binary and processed as a 64 k page number to be added as an offset to all of the following records until a new record type 02 is reached. Record type 01 indicates an End of File (EOF) record. If address 0000, 0001 or 0002 were programmed, these addresses are forced to 0c3h, 00 and 01, respectively. This is the code for a jump to boot control area, rather than the normal modem code. This step ensures that the boot control area of the flash part is not corrupted. READ AND PROCESS FILE routine 810 reads through the records in the HEX file until all records have been read, processed and stored into the memory buffer in the host PC. After the last record has been processed, the READ AND PROCESS FILE routine 810 is completed. Referring again to FIG. 8A, after READ AND PROCESS FILE routine 810 is completed, flash control program 800 queries the user ensure that the correct file to be programmed into the modem has been identified. If not, the program exits. Otherwise, flash control program 800 continues with PROGRAM FILE INTO PRODUCT routine 820. FIG. 8C shows a detailed flow diagram of PROGRAM FILE INTO PRODUCT routine 820. The present modem system uses the well-known and widely used AT command set. As is well-known in the art, the AT command set allows a user to control a modem by entering commands through a computer keyboard. The AT command set can be used to direct the modem to perform functions such as accessing a telephone line, taking the receiver off-hook, dialing and hanging up. The AT command set can also be used for more intelligent functions such as downloading or uploading files. Many of these more intelligent functions of the AT command set are used in the present modem system, as described in more detail below. The AT command set is used in the PROGRAM FILE INTO PRODUCT ROUTINE 820. A general overview of the PROGRAM FILE INTO PRODUCT routine 820 will now be described with reference to Table 1 and Table 2. The handshaking procedure which negotiates the transfer baud rate between the host PC and modem, which was discussed above is shown in Table 1. The AT command set shown and described in Table 2 is used to control the modem. All data sent is 8 bits, no parity and 1 stop bit.
Referring now to FIG. 8C, the serial port is initialized to 19200 baud, and is set for packets of 8 bits, no parity and 1 stop bit. AT*FS is a special command which tells the modem to jump to address zero, which is equivalent to powering on the modem. At that point, the host PC and modem engage in a handshaking procedure to negotiate the transfer baud rate, shown in tabular form in Table 1 above. Pursuant to this handshaking procedure, the host PC starts sending capital 'M's to the modem at an initial baud rate of 19200. The host PC sends 'M's until it receives a 'U' response from the modem. Timeout is controlled by the modem side as described below with respect to FIG. 9A. The host PC continues to send 'M' at 19200 baud until a 'U' is received. In the normal case, the modem will respond with a 'U' within 30 milliseconds. At that point, the PC will send back a 'D' and the modem responds within 300 ms with either 'J', 'K' or 'M', depending on the modem version and the corresponding baud rate at which it can run. If the modem responds with a 'J', the computer assumes a baud rate of 19200. If the modem responds with a 'K', the computer can choose 38400 or 19200 baud. A response of 'M' means that the modem can be run at 9600, 19200, 38400, 57600 or 115.2 k baud. The PC sends I, J, K or M to set the speed. The host PC and modem then each initialize the negotiated baud rate and configure accordingly. The modem is now prepared to receive the AT command set as shown in Table 2:
Next, the host PC sends an ATI1 command. The ATI1 command contains the boot control program version number. The version number determines the packet size, which can range from 128 bytes to 4 k byte packet size depending on the version number received. The host PC then sets the max packet size according to the version number received. Next, as shown in control box 880 in the top right of FIG. 8C, the host PC initializes pointers to the top of the RAM buffer which was allocated in control box 804 shown on FIG. 8A, and in which the processed and sorted updated operating code to be programmed into the flash PROM in the modem is stored. Once the pointers are initialized to the top of the RAM buffer in the host PC, control block 882 commands the PC to check a software protect switch which when enabled prevents overwriting of the program area of the flash PROM in which the boot control program is stored, or which when disabled allows portions of the boot control program to be updated. For normal use the software protect switch is enabled to prevent erroneous overwriting of the boot control program area. However, for R&D or manufacturing purposes it may be necessary to update or reprogram the boot control area. The software protect switch thus provides a software "back door" which allows access to the area of the flash PROM where the boot control program is stored. Referring again to FIG. 8C, the host PC begins to build a packet which will be sent to the modem over the serial port. In the control blocks 884 and 886 the host PC builds a packet by searching through the HEX files in the RAM buffer, searching for contiguous non-blank pages. A HEX file blank page is defined as a page programmed to all FF. Whenever a non-blank page is found the packet length is incremented. Variable length packets may be sent in sizes up to the specified max packet length determined by version number as described above. Once a blank page is found or the max packet length is reached, the packet is complete and ready to be transferred to the modem over the RS232 serial port. The packet built by the process shown in control blocks 884 and 886 includes a header portion and a data portion. The header portion includes a length field created by the host PC as it builds of the packet. The header portion also includes an address field which contains the physical starting address of where the data is to be placed in the flash PROM. The data portion includes the updated program data bytes and an XOR'd checksum. The packet format is shown in Table 3.
After the packet is built, the host PC sends the command ATFLP to the modem, the command for program a packet. Upon receipt of the ATFLP command, the modem responds with a 'G'. The host PC then transmits the data packet pointed to by the RAM buffer pointer. After the packet is received by the modem, the modem generates its own checksum based on the data received and compares it to the checksum sent by the host PC. If they are equivalent, the modem responds with 'OK', and the received code is programmed into the flash PROM address pointed to by the Address High, Middle, and Low bytes. Otherwise the modem responds with an error. The host PC will run through the programming loop, searching through the RAM buffer, creating packets and sending packets to the modem until the programming is complete or until 5 consecutive errors occur. After the host PC has sent all the packets, as determined by the DONE PROGRAMMING query, the host PC sends an ATFLEND command to signal that programming is completed. After the file has been programmed, an exit routine, shown in FIG. 8A is run in which timers are shut down and the state of the screen is restored. The user is informed that the program is completed or was terminated due to error. The program then jumps to the normal modem code. Detailed Description of the Boot Control Program for a First Embodiment of the Present Invention FIGS. 9A and 9B show a flow diagram of the boot control program. FIGS. 9A and 9B show the same programming procedure as described above with respect to FIGS. 8A-8C, except that FIGS. 8A-8C were described from the perspective of the host PC and FIGS. 9A and 9B are described from the perspective of the modem. The program begins with power up or AT*FS. The serial port between modem and host PC is initialized for 19200 baud. At this point the modem also copies the program code into RAM. The boot control program is run out of RAM while the flash PROM is reprogrammed. This is because certain bits in flash PROM U7 are toggled during reprogramming and therefore the boot control program must be copied to RAM to avoid corruption of the boot control code. Next, the handshaking protocol described above with respect to FIG. 8C is performed. The modem initializes a counter for 30 milliseconds. If the modem receives an 'M' from the host PC, the modem responds with a 'U'. If no 'M' is received, the counter is decremented. The loop will timeout after 30 ms if no 'M' is received. The number of times through the loop is dependent on the crystal speed of the modem, but is equivalent to 30 milliseconds. When the 'M' is received and the 'U' response is sent, another counter is initialized to 300 milliseconds. If a 'D' is received from the host PC within the 300 ms timeout, the modem responds with a 'J', 'K' or an 'M', depending of the baud rate at which the modem can run. The host PC then sends either 'I', 'J', 'K', 'L' or M, and both the host PC and the modem configure their baud rates according to the negotiated speed. The AT commands ATFLP, ATFLEND or ATIx can now be received by the modem. Flow diagrams showing the programming procedures on receipt of these commands are shown in FIGS. 9B-9D. FIG. 9B shows the control flow upon receipt of the ATFLP command. The modem first responds with a 'G' to indicate that the ATFLP command was received. Next, the packet length bytes and programming address bytes are received from the host PC. A counter is initialized to the length of a packet, and the checksum is initialized to 0. The modem next runs through a loop, getting each data byte and calculating a new checksum by XOR'ing the checksum from the previous iteration through the loop with the data received. The modem continues through the loop, decrementing the counter each iteration until the count equals 0, indicating that the entire packet was received. Next, the modem receives the checksum data byte which was generated by the host PC. If the checksum data byte generated by the host PC is equal to the checksum generated by the modem, the data bytes are programmed into the programming address sent with the packet into the flash PROM and an 'OK' response is sent to the host PC. If the checksums are not equal, an error message is sent to the host PC. FIG. 9C shows the flow diagram for the ATFLEND command. As discussed above, the ATFLEND command occurs when programming of the flash PROM is completed. If the command ATFLEND is received, the serial port is disabled and a jump to the normal modem code is performed. FIG. 9D shows other commands ATIx, where x=0, 1, 2 or 3. ATI0 commands the modem to respond with a product identification code. ATI1 commands the modem to respond with a boot version number, which is the version of the boot control program installed in the modem. The boot version number is important because different versions may require different packet lengths. ATI2 is for identification of a basic modem or hardware platform. MT1432xx indicates a derivative of the basic MT1432 platform, for example. These could become more specific to facilitate a more intelligent host interface. ATI3 can be used to indicate country types, special defaults, or for future expansion of making a smarter PC host interface. Functional Description of Upgrade Control Program for a Second Embodiment of the Modem System A second embodiment of the modem system also includes two control programs which control the remote in-circuit reprogramming of system firmware, a flash control program and a boot control program. However, in this embodiment the flash control program runs in the remote PC (i.e., the bulletin board) to process the updated operating code before downloading the code to the modem. The updated code is converted by a resident flash control program in the bulletin board from a PC Intel HEX file format into packets containing the updated code which are actually sent to the modem. Each packet contains a field containing the packet length, the address at which to store the updated code, the actual program data and a checksum. The boot control program running in the modem checks that the packet was correctly received and stores it until all packets are received. Reprogramming of flash PROM U7 begins after all packets are received. In one embodiment of present invention addresses which are included in the received packets are stored in RAM circuit 216. These addresses are used to subsequently program the updated operating code into flash PROM U7. In another embodiment of the present invention the modem organizes incoming packet data using the address information, rather than storing the address information. The address information is instantly used to store the packetized updated operating code in RAM circuit 216 in proper order. This order is a mirror image of the order in which flash PROM U7 will be programmed. This embodiment requires less RAM circuit 216 memory, since the address information need not be saved in the storage to RAM circuit 216. In summary, the flash control programs control the bulletin board side of the process of in-circuit reprogramming of flash PROM U7. The boot control program controls the modem side. As described above, flash PROM U7 is an in-circuit programmable and electrically erasable read only memory. As is well known to those of skill in the art, these memory chips allow in-circuit reprogramming of the operating code and parameters which are stored in the flash PROM chip U7. Although the present modem system is described with respect to a particular flash PROM U7, it shall be understood that any in-circuit reprogrammable memory configuration could be used without departing from the scope of the present invention. Before flash PROM U7 is assembled in the modem circuit, the boot control program is burned, or programmed into flash PROM U7 using conventional PROM programmers and programming techniques. This embodiment of the present invention has several advantages. A direct programming of the Flash PROM circuit U7 is accomplished without the need to have the host PC process the files prior to programming the modem. Detailed descriptions of the flash control program and boot control program will now be given. This embodiment of the present invention is not limited to a DOS operating system. The preferred modem system can also be used with a UNIX-based operating system, Macintosh operating system, or any of a number of operating system platforms simply by customizing the user interface to run on the desired operating system. Detailed Description of Flash Control Program for a Second Embodiment of the Present Invention The flash control program is used to control the reprogramming of updated operating code and parameters into the flash part of the modem. The updated operating code is distributed to the modem according to the procedure shown in FIG. 10. The updated operating code is resident on the Bulletin Board in the Intel MCS-86 HEX format. The HEX files may be converted using the flash control program every time a new modem is updated, or the HEX files may be converted once using the flash control program and downloaded every time a new modem is updated. The remote PC may be a bulletin board or another PC with modem access. The HEX files were described in the section entitled "Detailed Description of Flash Control Program For a First Embodiment of the Present Invention", above. FIG. 11A shows a detailed flow diagram of the flash control program 1100. First, the internal environment and variables are initialized. This embodiment of the flash control program 1100 accepts either command line parameters or can be run in a menu driven mode. The present state of the user interface screen is saved and cleared while the field upgrade control program is running. The screen is saved for later restoration after the reprogramming is completed. Flash control program 1100 continues at control block 1102, which starts the help system. The help system reports onscreen status messages to the user (in this embodiment, the bulletin board operator) during various stages of reprogramming. At times information may be requested from the user. Also, error messages and possible courses of action are displayed when appropriate. Next, flash control program 1100 reads the setup file to determine which serial port the modem is connected through, the appropriate baud rate and other necessary setup information. The serial port is then initialized according to the setup information obtained. Control block 1104 allocates a 128 kbyte memory buffer in the remote PC (in this embodiment, the bulletin board PC). This memory buffer is used to store processed HEX files containing the updated operating code to be programmed into the flash PROM in the modem. Processing of the HEX files is described in detail below with respect to FIG. 11B. If "AUTOMATIC MODE" is set at query 1106, flash control program 1100 automatically runs the user through the reprogramming procedure. However for certain manufacturing and R&D purposes, it is desirable for the user to have more control over the reprogramming procedure. Thus, automatic mode can be disabled. When automatic mode is disabled, the flash control program checks whether the name of the HEX file to be programmed is present on the command line. If not, a user "PROCESS MENU" will appear on the screen at control block 1107 with the choices "PORT SETUP," "READ FILE," "PROGRAM," or "EXIT." The user can then select the functions to be performed. If the HEX file name was on the command line, the flash control program continues with READ AND PROCESS FILE routine 1110 described in detail below. Otherwise, in AUTOMATIC MODE, flash control program 1100 continues at the top right portion of FIG. 11A with control block 1108. Here all HEX files present in the remote PC are found and their names displayed onscreen. The user chooses the name of the file to be programmed into the modem. If the desired file is not listed, the user can press the ESC key to exit the program. Although the bytes of each record in the HEX files are sequential, the HEX records themselves are in no particular order within the file. The file must therefore be processed and sorted into a format which can be programmed into the modem. READ AND PROCESS FILE routine 1110 reads the standard Intel HEX files stored in the remote PC and performs the necessary HEX file processing. FIG. 11B shows a detailed flow diagram of the READ AND PROCESS FILE routine 1110. The purpose of READ AND PROCESS FILE routine 1110 is to convert the ASCII HEX characters contained in the HEX records to a binary format appropriate for programming into flash PROM U7. Routine 1110 begins with an update of the onscreen help display. Next, the memory buffer is "zapped", i.e., set to all FF hex (all 1 binary). This corresponds to the erased state of flash PROM U7. Next the HEX file is opened for read access and the first HEX record is read. The record is then parsed to check syntax and to determine the record type indicated by the record type field of each HEX record as described above. If the record is type 0 the record is a data record. The record is processed as a data to be loaded in the memory buffer at the current memory pointer, where the pointer is the current 64 k page plus the address supplied in the record. After the data is converted from a ASCII text to binary and stored to the memory buffer, the pointer is incremented to the next available space in the buffer. Record type 02 indicates an extended address record. The information in these records is converted from ASCII text to binary and processed as a 64 k page number to be added as an offset to all of the following records until a new record type 02 is reached. Record type 01 indicates an End of File (EOF) record. If address 0000, 0001 or 0002 were programmed, these addresses are forced to 0c3h, 00 and 01, respectively. This is the code for a jump to boot control area, rather than the normal modem code. This step ensures that the boot control area of the flash part is not corrupted. READ AND PROCESS FILE routine 1110 reads through the records in the HEX file until all records have been read, processed and stored into the memory buffer in the remote PC. After the last record has been processed, the READ AND PROCESS FILE routine 810 is completed. Referring again to FIG. 11A, after READ AND PROCESS FILE routine 1110 is completed, flash control program 1100 queries the user ensure that the correct file to be programmed into the modem has been identified. If not, the program exits. Otherwise, flash control program 1100 continues with PROGRAM FILE INTO PRODUCT routine 1120. FIG. 11C shows a detailed flow diagram of PROGRAM FILE INTO PRODUCT routine 1120. A general overview of the PROGRAM FILE INTO PRODUCT routine 1120 will now be described with reference to Table 4 and Table 5. The handshaking procedure which negotiates the transfer baud rate between the remote PC and modem, which was discussed above is shown in Table 4 (next page). The AT command set shown and described in Table 5 is used to control the modem. All data sent is 8 bits, no parity and 1 stop bit.
Referring now to FIG. 11C, the serial port is initialized at the remote PC to match the transmission parameters (baud rate, packet size, stop bits) of the modem receiving the upgraded operating code. The modems establish the transmission parameters when first communicating in the data mode (see the first step of FIG. 10). The modems have a default baud rate of 19200 baud, if no other speed is established. The remote PC and modem engage in a handshaking procedure to negotiate the transfer baud rate, shown in tabular form in Table 4 above. Pursuant to this handshaking procedure, the remote PC starts sending capital 'M's to the modem at the baud rate established between the remote PC modem and the modem receiving the updated operating code. The remote PC sends 'M's until it receives a 'U' in response from the modem. Timeout is controlled by the modem side as described below with respect to FIG. 12A. The remote PC continues to send 'M' at the established baud rate until a 'U' is received. In the normal case, the modem will respond with a 'U' within 30 milliseconds. At that point, the PC will send back a 'D' and the modem responds within 300 ms with either 'J', 'K' or 'M', depending on the modem version and the corresponding baud rate at which it can run. If the modem responds with a 'J', the computer assumes that no change in speed is necessary. If the modem responds with a 'K', the computer can choose 38400 or 19200 baud. A response of 'M' means that the modem can be run at 9600, 19200, 38400, 57600 or 115.2 k baud. The PC sends I, J, K or M to set the speed. The remote PC and modem then each initialize the negotiated baud rate and configure accordingly. The modem is now prepared to receive the AT command set as shown in Table 5:
Next, the remote PC sends an ATI1 command. The ATI1 command contains the boot control program version number. The version number determines the packet size, which can range from 128 bytes to 4 k byte packet size depending on the version number received. The remote PC then sets the max packet size according to the version number received. Next, as shown in control box 1180 in the top right of FIG. 11C, the remote PC initializes pointers to the top of the RAM buffer which was allocated in control box 1104 shown on FIG. 11A, and in which the processed and sorted updated operating code to be programmed into the flash PROM in the modem is stored. Once the pointers are initialized to the top of the RAM buffer in the remote PC, control block 1182 commands the PC to check a software protect switch which when enabled prevents overwriting of the program area of the flash PROM in which the boot control program is stored, or which when disabled allows portions of the boot control program to be updated. For normal use the software protect switch is enabled to prevent erroneous overwriting of the boot control program area. However, for R&D or manufacturing purposes it may be necessary to update or reprogram the boot control area. The software protect switch thus provides a software "back door" which allows access to the area of the flash PROM where the boot control program is stored. Referring again to FIG. 11C, the remote PC begins to build a packet which will be sent to the modem over the serial port. In the control blocks 1184 and 1186 the remote PC builds a packet by searching through the HEX files in the RAM buffer, searching for contiguous non-blank pages. A HEX file blank page is defined as a page programmed to all FF. Whenever a non-blank page is found the packet length is incremented. Variable length packets may be sent in sizes up to the specified max packet length determined by version number as described above. Once a blank page is found or the max packet length is reached, the packet is complete and ready to be transferred to the modem. The packet built by the process shown in control blocks 1184 and 1186 includes a header portion and a data portion. The header portion includes a length field created by the remote PC as it builds the packet. The header portion also includes an address field which contains the physical starting address of where the data is to be placed in the flash PROM. The data portion includes the updated program data bytes and an XOR'd checksum. The packet format is shown in Table 6:
After the packet is built, the remote PC sends the command ATFLP to the modem, the command for program a packet. Upon receipt of the ATFLP command, the modem responds with a 'G'. The remote PC then transmits the data packet pointed to by the RAM buffer pointer. After the packet is received by the modem, the modem generates its own checksum based on the data received and compares it to the checksum sent by the remote PC. If they are equivalent, the modem responds with 'OK', and the received code is stored in RAM circuit 216. In one embodiment the received code is stored in an order determined by the received Address High, Middle and Low bytes accompanying the received code. In an alternate embodiment the flash PROM address of the Address High, Middle, and Low bytes is stored as well. After the entire updated operating code is transferred to RAM circuit 216 the remote PC sends an ATFLEND command to initiate programming of the flash PROM U7, as described below. Otherwise the modem responds with an error. The remote PC will run through the programming loop, searching through the RAM buffer, creating packets and sending packets to the modem until the programming is complete or until 5 consecutive errors occur. After the remote PC has sent all the packets, as determined by the DONE PROGRAMMING query, the remote PC sends an ATFLEND command to signal that RAM 216 has the entire updated operating code. After the file has been programmed, an exit routine, shown in FIG. 11A is run in which timers are shut down and the state of the screen is restored. The user is informed that the program is completed or was terminated due to error. The program then terminates. Detailed Description of the Boot Control Program for a Second Embodiment of the Present Invention FIGS. 12A and 12B show a flow diagram of the boot control program, described from the perspective of the modem. The program begins upon reception of the upgrade command AT*FS1. At this point the modem copies the program code into RAM. The boot control program is run out of RAM while the flash PROM is reprogrammed. This is because certain bits in flash PROM U7 are toggled during reprogramming and therefore the boot control program must be copied to RAM to avoid corruption of the boot control code. Next, the handshaking protocol described above with respect to the flash control program is performed. The modem waits for the remote PC to exit data communications software and process the upgrade file (if updated operating programs are not already preprocessed and ready at the remote PC location). If the modem receives an 'M' from the remote PC, the modem responds with a 'U'. If no 'M' is received, the counter is decremented. The loop will timeout after a time adequate for the Remote PC to enter command mode and process a file per the AT*FS1 command if no 'M' is received. The number of times through the loop is dependent on the crystal speed of the modem, but depends on a time adequate for the Remote PC to enter command mode and process a file per the AT*FS1 command. When the 'M' is received and the 'U' response is sent, another counter is initialized to 300 milliseconds. If a 'D' is received from the remote PC within the 300 ms timeout, the modem responds with a 'J', 'K' or an 'M', depending of the baud rate at which the modem can run. The remote PC then sends either 'I', 'J', 'K', 'L' or M, and both the remote PC and the modem configure their baud rates according to the negotiated speed. The AT commands ATFLP, ATFLEND or ATIx can now be received by the modem. Flow diagrams showing the programming procedures on receipt of these commands are shown in FIGS. 12B-12D. FIG. 12B shows the control flow upon receipt of the ATFLP command. The modem first responds with a 'G' to indicate that the ATFLP command was received. Next, the packet length bytes and programming address bytes are received from the remote PC. A counter is initialized to the length of a packet, and the checksum is initialized to 0. The modem next runs through a loop, getting each data byte and calculating a new checksum by XOR'ing the checksum from the previous iteration through the loop with the data received. In one embodiment, the data bytes are collected in RAM circuit 216, as described below. Other embodiments may allow the bytes to be programmed directly to flash PROM 217 if large enough to accommodate two sets of operating code. That way, the functioning of the modem is not compromised by a failed updated code programming attempt. The modem continues through the loop, decrementing the counter each iteration until the count equals 0, indicating that the entire packet was received. Next, the modem receives the checksum data byte which was generated by the remote PC. If the checksum data byte generated by the remote PC is equal to the checksum generated by the modem, the data bytes are stored into RAM circuit 216 according to the programming address sent with the packet and an 'OK' response is sent to the remote PC. If the checksums are not equal, an error message is sent to the remote PC. FIG. 12C shows the flow diagram for the ATFLEND command. As discussed above, the ATFLEND command occurs when RAM circuit 216 contains the entire updated operating code. If the command ATFLEND is received and all packets are received without error, the serial port is disabled and flash PROM U7 is programmed with the entire updated operating code stored in RAM circuit 216. A hard boot of the modem is performed and the modem executes the updated operating code. If the transfer has errors, the modem begins executing the normal modem code without updating flash PROM U7. FIG. 12D shows other commands ATIx, where x=0, 1, 2 or 3. ATI0 commands the modem to respond with a product identification code. ATI1 commands the modem to respond with a boot version number, which is the version of the boot control program installed in the modem. The boot version number is important because different versions may require different packet lengths. ATI2 is for identification of a basic modem or hardware platform. MT1432xx indicates a derivative of the basic MT1432 platform, for example. These could become more specific to facilitate a more intelligent remote interface. ATI3 can be used to indicate country types, special defaults, or for future expansion of making a smarter PC remote interface. CONCLUSION The two embodiments described were given to demonstrate two embodiments of the present invention. Other embodiments are possible which do not deviate from the scope and spirit of the present invention. For example, other embodiments may incorporate different handshaking symbols and procedures without departing from the scope and spirit of the teaching of the present invention. Although specific embodiments have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that any system which is calculated to achieve the same purpose may be substituted for the specific embodiments shown. These applications are intended to cover any adaptations or variations of the present invention. Therefore, it is manifestly intended that this invention be limited only by the claims and equivalents thereof.
|
Same subclass Same class Consider this |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
