Logo
MSP430USBDevelopersPackage_5_20_06_02
Msc_state_machine_api

Functions

uint8_t USBMSC_pollCommand (void)
 
int16_t MSCToHostFromBuffer ()
 
int16_t MSCFromHostToBuffer ()
 
uint8_t USBMSC_processBuffer (void)
 
uint8_t USBMSC_getState ()
 
uint8_t USBMSC_updateMediaInformation (uint8_t lun, struct USBMSC_mediaInfoStr *info)
 
uint8_t USBMSC_registerBufferInformation (uint8_t lun, uint8_t *RWbuf_x, uint8_t *RWbuf_y, uint16_t size)
 
uint8_t Scsi_Cmd_Parser (uint8_t opcode)
 
uint8_t Scsi_Send_CSW (uint8_t intfNum)
 
void Msc_ResetStateMachine (void)
 
void Msc_ResetFlags (void)
 
void Msc_ResetStruct (void)
 
void SET_RequestsenseNotReady (void)
 
void SET_RequestsenseMediaNotPresent (void)
 
void MscResetCtrlLun (void)
 
USBMSC_RWbuf_InfoUSBMSC_fetchInformationStructure (void)
 

Detailed Description

Function Documentation

USBMSC_RWbuf_Info* USBMSC_fetchInformationStructure ( void  )

Returns a pointer to the USBMSC_Rwbuf_Info structure instance maintained within the API.

Returns a pointer to the USBMSC_Rwbuf_Info structure instance maintained within the API. See Sec. 8.3.6 of "Programmer's Guide: MSP430 USB API Stack for CDC/PHDC/HID/MSC" for information on using this structure. This function should be called prior to USB enumeration; that is, prior to calling USB_connect().

Returns
A pointer to an application-allocated instance of USBMSC_RWBuf_Info, which will be used to exchange information related to buffer requests from the API to the application.
uint8_t USBMSC_pollCommand ( void  )

Checks to See if a SCSI Command has Been Received.

Checks to see if a SCSI command has been received. If so, it handles it. If not, it returns having taken no action. The return values of this function are intended to be used with entry of low-power modes. If the function returns USBMSC_OK_TO_SLEEP, then no further application action is required; that is, either no SCSI command was received; one was received but immediately handled; or one was received but the handling will be completed in the background by the API as it automatically services USB interrupts. If instead the function returns USBMSC_PROCESS_BUFFER, then the API is currently servicing a SCSI READ or WRITE command, and the API requires the application to process a buffer. (See Sec. 8.3.6 of "Programmer's Guide: MSP430 USB API Stack for CDC/PHDC/HID/MSC" for a discussion of buffer processing.) Note that even if the function returns these values, the values could potentially be outdated by the time the application evaluates them. For this reason, it's important to disable interrupts prior to calling this function. See Sec. 8.3.5 of "Programmer's Guide: MSP430 USB API Stack for CDC/PHDC/HID/MSC" for more information.

Returns
USBMSC_OK_TO_SLEEP or USBMSC_PROCESS_BUFFER
uint8_t USBMSC_processBuffer ( void  )

This function should be called by the application after it has processed a buffer request.

Parameters
USBMSC_Rwbuf_Info*RWBufInfoPass the value received from USBMSC_fetchInformationStructure().

This function should be called by the application after it has processed a buffer request. It indicates to the API that the application has fulfilled the request. Prior to calling this function, the application needs to write a return code to rwInfo.returnCode. This code should reflect the result of the operation. The value may come from the file system software, depending on the application. See Sec. 8.3.6 of "Programmer's Guide: MSP430 USB API Stack for CDC/PHDC/HID/MSC" for a list of valid return codes.

Returns
USB_SUCCEED
uint8_t USBMSC_registerBufferInformation ( uint8_t  lun,
uint8_t *  RWbuf_x,
uint8_t *  RWbuf_y,
uint16_t  size 
)

Gives the API a Buffer to Use for READ/WRITE Data Transfer.

Parameters
lunis the Lun number.
*RWbuf_xis the address of an X-buffer. If null, then both buffers are de-activated.
*RWbuf_yis the address of an Y-buffer. (Double-buffering is not supported in this version of the API.)
sizeis the size, in bytes, of the buffers.

Gives the API a buffer to use for READ/WRITE data transfer. size indicates the size of the buffer, in bytes.

NOTE: Currently, only single-buffering is supported, so RWbuf_y should be set to null. If the application intends to allocate the buffer statically, then this function needs only to be called once, prior to any READ/WRITE commands being received from the host. Most likely this would happen during the application's initialization functions.

NOTE: This API has to be called after the call to USBMSC_updateMediaInformation() at the beginning of execution.

However, this function optionally enables dynamic buffer management. That is, it can activate and de-activate the buffer, by alternately assigning a null and valid address in RWbuf_x. This is useful because the buffer uses a significant portion of the RAM resources (typically 512 bytes). This memory is not needed when USB is not attached or suspended.

If doing this, it's important that the application re-activate the buffer when USB becomes active again, by issuing another call to the function, this time using valid buffer information. If the API needs the buffer and doesn't have it, it will begin failing READ/WRITE commands from the host. The re-activation can take place within USB_handleVbusOffEvent().

size must be a multiple of a block size - for FAT, a block size is typically 512 bytes. Thus values of 512, 1024, 1536, etc. are valid. Non-multiples are not valid.

The function returns USB_SUCCEED every time. It is up to the application to ensure that the buffers are valid.

Returns
USB_SUCCEED
uint8_t USBMSC_updateMediaInformation ( uint8_t  lun,
struct USBMSC_mediaInfoStr info 
)

Informs the API of the Current State of the Media on LUN lun.

Parameters
lunis the logical unit (LUN) on which the operation is taking place. Zero-based. (This version of the API only supports a single LUN.)
infois a structure that communicates the most recent information about the medium.

Informs the API of the current state of the media on LUN lun. It does this using an instance info of the API-defined structure USBMSC_mediaInfoStr. The API uses the information in the most recent call to this function in automatically handling certain requests from the host. In LUNs that are marked as not removable in USBMSC_CONFIG, this function should be called once at the beginning of execution, prior to attachment to the USB host. It then no longer needs to be called.

In LUNS that are marked as removable, the media information is dynamic. The function should still be called at the beginning of execution to indicate the initial state of the media, and then it should also be called every time the media changes.

See Sec. 8.3.4 of "Programmer's Guide: MSP430 USB API Stack for CDC/PHDC/HID/MSC" for more about informing the API of media changes.

Returns
USB_SUCCEED