# 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
…
- 39
- 40
- 41
- 42
- 43
…
- 311
- 312

Remarks
None
Preconditions
None
Function
void USBCtrlEPAllowStatusStage(void);
1.4.1.1.1.5 USBDeferINDataStage Function
This function will cause the USB hardware to continuously NAK the IN token packets sent from the host, during the data
stage of a device to host control transfer. This allows the firmware more time to process and prepare the IN data packets
that will eventually be sent to the host. This is also useful, if the firmware needs to process/prepare the IN data in a different
context than what the USBDeviceTasks() function executes at.
Calling this function (macro) will assert ownership of the currently pending control transfer. Therefore, the USB stack will not
STALL when it reaches the data stage of the control transfer, even if the firmware has not (yet) called the
USBEP0SendRAMPtr() or USBEP0SendROMPtr() API function. However, the application firware must still (eventually, once
it is ready) call one of the aforementioned API functions.
Example Usage:
1. Host sends a SETUP packet to the device, requesting a device to host control transfer, with data stage.
2. USBDeviceTasks() executes, and then calls the USBCBCheckOtherReq() callback event handler. The
USBCBCheckOtherReq() calls the application specific/device class specific handler that detects the type of control
transfer.
3. If the firmware needs more time to prepare the first IN data packet, or, if the firmware wishes to process the command in
a different context (ex: if USBDeviceTasks() executes as an interrupt handler, but the IN data stage data needs to be
prepared in the main loop context), then it may call USBDeferINDataStage(), in the context of the
USBCBCheckOtherReq() handler function.
4. If the firmware called USBDeferINDataStage() in step #3 above, then the hardware will NAK the IN token packets sent by
the host, for the IN data stage.
5. Once the firmware is ready, and has successfully prepared the data to be sent to the host in fulfillment of the control
transfer, it should then call USBEP0SendRAMPtr() or USBEP0SendROMPtr(), to prepare the USB stack to know how
many bytes to send to the host, and from what source location.
6. The firmware should now call USBCtrlEPAllowDataStage(). This will allow the data stage to complete. The USB stack will
send the data buffer specified by the USBEP0SendRAMPtr() or USBEP0SendROMPtr() function, when it was called.
7. Once all data has been sent to the host, or if the host performs early termination, the status stage (a 0-byte OUT packet)
will complete automatically (assuming the firmware did not call USBDeferStatusStage() during step #3).
File
usb_device.h
Syntax
void USBDeferINDataStage();
Remarks
Section 9.2.6 of the official USB 2.0 specifications indicates that the USB device must return the first IN data packet within
500ms of the start of the control transfer. In order to meet this specification, the firmware must call USBEP0SendRAMPtr() or
USBEP0SendROMPtr(), and then call USBCtrlEPAllowDataStage(), in less than 500ms from the start of the control transfer.
If the firmware calls USBDeferINDataStage(), it must eventually call USBEP0SendRAMPtr() or USBEP0SendROMPtr(), and
then call USBCtrlEPAllowDataStage(). If it does not do this, the control transfer will never be able to complete.
1.4 Library Interface MLA - USB Library Help Device/Peripheral
41

- 1
- 2
…
- 39
- 40
- 41
- 42
- 43
…
- 311
- 312