brp_Main_Bf3UploadContinue()

brp_errcode brp_Main_Bf3UploadContinue	(	brp_protocol	protocol,
		unsigned	DataAdr,
		brp_buf	Data,
		size_t	Data_len,
		bool *	Reconnect,
		bool *	Continue,
		unsigned *	ReqDataAdr,
		unsigned *	ReqDataLen,
		bool *	ContainsEstimation,
		bool *	ContainsReconnectRetryTimeout,
		unsigned *	ReconnectRetryTimeout,
		unsigned *	EstimatedNumberOfBytes,
		unsigned *	EstimatedTimeOverhead
	)

This command is used to transfer the data of a BEC2/BF3 file block by block to the reader. The host transfers the data block of the BEC2/BF3 file which has been requested by the reader previously. The response parameter RequiredAction indicates how the host has to proceed afterwards:

• Transfer the next data block.
• Disconnect and reconnect to the reader.
• Upload completed - no more data to transfer.

For more details about implementation, please refer to the help topic[ Implement wired upload via the host](https://docs.baltech.de/developers/implement-wired-upload.html) .

Parameters

[in]	protocol	used to execute the command
[in]	DataAdr	Address of data block that is being transferred. Has to correspond to the ReqDataAdr parameter in the reader's response to the previous command (i.e. the last Bf3UploadContinue or the Main.Bf3UploadStart command).
[in]	Data	Data requested by the reader
[in]	Data_len
[out]	Reconnect	If true , the host has to disconnect and reconnect to the reader.
[out]	Continue	If true , the host has to continue by transferring the next data block of the BEC2/BF3 file. If false , the reader has received all required data blocks: Upload is completed.
[out]	ReqDataAdr	Start byte of next data block requested by the reader
[out]	ReqDataLen	Number of bytes of next data block requested by the reader. This value may also be 0.
[out]	ContainsEstimation	If true , the response contains estimation information fields.
[out]	ContainsReconnectRetryTimeout	If true , the response contains the ReconnectRetryTimeout field.
[out]	ReconnectRetryTimeout	If a reconnect is requested, this field specifies how long the host has to try (time period in ms). You need to add the ReconnectRetryTimout to the OS-specific base reconnect timeout. For Windows, we recommend a base reconnect timeout of 10000 ms. For all other platforms, please check how long it takes for a reader to be available again after a reboot.
[out]	EstimatedNumberOfBytes	This is an estimation of the total amount of data bytes that have to be transferred from the host to the reader to upload the current BEC2/BF3 file. ** This information is only returned once as soon as the reader has gathered enough data to perform this estimation. Note: In special cases, e.g. if you re-perform a firmware upload that was aborted before, the reader returns a worst-case estimation that may be higher than the actual amount of data bytes to transfer. **
[out]	EstimatedTimeOverhead	This is an estimation of the total time in ms the reader requires for additional internal tasks during the upload, which lead to occasional communication pauses. If the reader can maintain communication during such a task, it keeps responding to calls of the Bf3UploadContinue command; the ReqDataLen response parameter will then be set to 0. If the reader can't maintain communication, it asks for a reconnect with an additional retry timeout, which is indicated by the optional ReconnectRetryTimeout parameter. This information is only returned once as soon as the reader has gathered enough data to perform this estimation.