3.5 Flow Control
During an update, a host uses commands to send the contents of a Client Update File to the client. There are several potential reasons why a client processor might not be able to process incoming commands or Client Update File data as fast as the host could theoretically transmit the Client Update File data to the client.
- Some microcontrollers don’t support executing code while erasing/writing Flash.
- In some scenarios the communication data rate may be greater than the Flash erase and write speed.
- Client firmware update routines may be a low priority background task with limited processor bandwidth allocation.
The MDFU Protocol uses the flow control mechanism described in this section to allow the client to slow down the update to a speed it is capable of supporting without command/data loss. This flow control mechanism allows the host to avoid sending commands and Client Update File data to the client when the client does not have adequate resources available (processing cycles, RAM buffer space, etc.) to process them.
3.5.1 Stop and Wait Flow Control with Time-outs
Host Stop and Wait
MDFU hosts know exactly how much data a client can receive at a time.
- MDFU clients have a single command reception buffer.
- MDFU hosts learn the size of this buffer during the Discovery phase of the update.
After sending a command to the client, hosts must stop and wait for a response to that command before sending additional commands/data.
The response from the client is an indication that the client is ready to receive another command.
If a response is corrupted, the response can produce a Transport Error instead of a correctly received response. Therefore, detecting a response Transport Error is another indication that the client has finished processing the prior command and is ready to receive a the next command.
Using this process, MDFU hosts avoid sending commands/data when MDFU clients are not ready to receive them, and hosts know when clients are ready to receive additional commands/data.
Host Time-outs
Host time-outs are necessary to avoid situations where command/response corruption could cause the host to wait forever for a response that will never come. Hosts will never see a response in a situation where a command/response is lost during transport:
- Some forms of corruption during transport result in commands/responses being lost and never fully received by a client/host.
- Lost commands are never processed by the client and do not generate a response from the client.
- Lost responses are never processed by the host.
Host time-outs provide the host with an opportunity to recover from commands/responses which have been completely lost. Hosts recover from lost commands/responses by resending those commands.
In order for hosts to honor the stop and wait flow control mechanism described above, hosts are not allowed to resend a command before clients have had enough time to process that command.
In the update Discovery phase, the host learns the maximum amount of time that the client takes to execute each command through the Client Command Time-out Parameter.
The host uses the command time-out parameter information to make sure that it does not time out and retry a command before the client has had sufficient time to complete the command execution.
Since the Get Client Info Command (GetClientInfo) is used to learn the command time-outs, there is no way to customize the time-out duration of the GetClientInfo command. The GetClientInfo command has a fixed time-out of one second.
3.5.2 Flow Control Algorithm Diagram
The following figure shows the MDFU Protocol flow control algorithm.
Figure Notes | |
Note 1: | This diagram is a simplification of the host processing algorithms intended to show the MDFU flow control mechanism. Please refer to the Host Command Generation and Response Processing section of the specification for the more detailed algorithms. |
Note 2: | If a command or response is corrupted in a way that results in the command or response being lost, no response will arrive and the time-out will expire. See the Client Command Time-out Parameter section for more details on the time-out values. |
Note 3: | Corruption detected in a response during reception produces a Transport Error. |
Note 4: | Responses which are received without any corruption detected are considered received responses. |