# Vault 7: Projects

This publication series is about specific projects related to the Vault 7 main publication.

### Protego

# MLA -- USB Library

20 December, 2013

- 1
- 2
…
- 41
- 42
- 43
- 44
- 45
…
- 311
- 312

USB connection, as the host needs to be able to communicate over EP0, in order to perform basic tasks including
enumeration.
The firmware should never call both USBDeferINDataStage() and USBDeferOUTDataStage() during the same control
transfer. These functions are mutually exclusive (a control transfer with data stage can never contain both IN and OUT data
packets during the data stage).
Preconditions
Before calling USBDeferOUTDataStage(), the firmware should first verify that the control transfer has a data stage, and that
it is of type host-to-device (OUT).
Function
void USBDeferOUTDataStage(void);
1.4.1.1.1.7 USBDeferStatusStage Function
Calling this function will prevent the USB stack from automatically enabling the status stage for the currently pending control
transfer from completing immediately after all data bytes have been sent or received. This is useful if a class handler or USB
application firmware project uses control transfers for sending/receiving data over EP0, but requires time in order to finish
processing and/or to consume the data.
For example: Consider an application which receives OUT data from the USB host, through EP0 using control transfers.
Now assume that this application wishes to do something time consuming with this data (ex: transmit it to and save it to an
external EEPconst device, connected via SPI/I2C/etc.). In this case, it would typically be desireable to defer allowing the
USB status stage of the control transfer to complete, until after the data has been fully sent to the EEPconst device and
saved.
If the USB class handler firmware that processes the control transfer SETUP packet determines that it will need extra time to
complete the control transfer, it may optionally call USBDeferStatusStage(). If it does so, it is then the responsibility of the
application firmware to eventually call USBCtrlEPAllowStatusStage(), once the firmware has finished processing the data
associated with the control transfer.
If the firmware call USBDeferStatusStage(), but never calls USBCtrlEPAllowStatusStage(), then one of two possibilities will
occur.
1. If the "USB_ENABLE_STATUS_STAGE_TIMEOUTS" option is commented in usb_config.h, then the status stage of the
control transfer will never be able to complete. This is an error case and should be avoided.
2. If the "USB_ENABLE_STATUS_STAGE_TIMEOUTS" option is enabled in usb_config.h, then the USBDeviceTasks()
function will automatically call USBCtrlEPAllowStatusStage(), after the "USB_STATUS_STAGE_TIMEOUT" has elapsed,
since the last quanta of "progress" has occurred in the control transfer. Progress is defined as the last successful
transaction completing on EP0 IN or EP0 OUT. Although the timeouts feature allows the status stage to [eventually]
complete, it is still preferable to manually call USBCtrlEPAllowStatusStage() after the application firmware has finished
processing/consuming the control transfer data, as this will allow for much faster processing of control transfers, and
therefore much higher data rates and better user responsiveness.
File
usb_device.h
Syntax
void USBDeferStatusStage();
Remarks
If this function is called, is should get called after the SETUP packet has arrived (the control transfer has started), but before
the USBCtrlEPServiceComplete() function has been called by the USB stack. Therefore, the normal place to call
USBDeferStatusStage() would be from within the USBCBCheckOtherReq() handler context. For example, in a HID
application using control transfers, the USBDeferStatusStage() function would be called from within the
USER_GET_REPORT_HANDLER or USER_SET_REPORT_HANDLER functions.
1.4 Library Interface MLA - USB Library Help Device/Peripheral
43

- 1
- 2
…
- 41
- 42
- 43
- 44
- 45
…
- 311
- 312