> 3.2 | Requirements for the Firmware Download Utility

> The host application or download utility must be designed to meet the requirements of the download process specified in the download protocol. See also Figure 7 and Figure 8 for detail.
> First of all, to start the download process, the host application has to send the AT^SFDL command to the module. This causes the module to reset, enter the firmware download mode and send the start pattern to the host application to notify that it is ready to receive records. Upon receipt of the start pattern (“ANSWER_OK” in the example below) the host application must start to send the first record. Optionally, we recommend that the buffer of the serial interface be purged before the module starts to send the first record.
> After each record the host application has to wait for an acknowledgment delivered by the module. If this is “OK”, the next record can be transferred. “BUSY” means that the module is still processing the record last received – in this case, the transfer must be halted until the next “OK” acknowledgment is received. A checksum verifies the correct transmission of each record. If a download error is detected, the module will send a “RETRY” message.
> The host application must be capable to evaluate the answer patterns received from the module and to correctly transmit the data.
> Once all records are successfully received, the module switches off automatically. To restart the module use the ignition line IGT.
> Appropriate examples are provided in Section 3.2.2.1 for ASC0 or ASC1 and in Section 3.2.3.1 for USB.

> Table 3: | Answer patterns required for generic download utility

> Answer pattern | Hex value | Function
> #define ANSWER_OK | 0x01 | After the reset caused by AT^SFDL, “ANSWER_OK” notifies the host application that the first record can be sent. After each successfully received record, “ANSWER_OK” notifies the host application that the next data record can be transferred.
> #define ANSWER_RETRY | 0x02 | Notifies that a failure was detected after verifying the checksum. The host application is requested to send the last record again and wait until this record is successfully received and acknowledged with “ANSWER_OK”.
> #define ANSWER_FATAL | 0x03 | Download failed at all. Possible causes: The firmware you are trying to download is not intended for this module type, or you are trying to install an older version. The currently installed software is not affected.
> #define ANSWER_BUSY | 0x04 | The module is still processing the record received. The transfer from the host application must be halted until the module sends the next “ANSWER_OK”. For example, “ANSWER_BUSY” may appear when the flash is erased on the module. This procedure usually takes a couple of seconds. In this case, “ANSWER_BUSY” is no error.