Difference between revisions of "USB Communication"

From WikiPrizm
Jump to navigationJump to search
(More info)
(My tny.im link is supposed to stay up for many years to come, and is certainly a more neutral link than the Omnimaga one, which appeared to be broken.)
Line 268: Line 268:
 
== Credits ==
 
== Credits ==
 
BrandonW<br>
 
BrandonW<br>
Simon Lother and Andreas Bertheussen for Protocol 7 info.  PDF released under Attribution-NonCommercial-NoDerivs 3.0 Unported (CC BY-NC-ND 3.0) license, located [http://www.omnimaga.org/index.php?action=dlattach;topic=5610.0;attach=13335 here].
+
Simon Lother and Andreas Bertheussen for Protocol 7 info.  PDF released under Attribution-NonCommercial-NoDerivs 3.0 Unported (CC BY-NC-ND 3.0) license, located [http://tny.im/dl/fxReverse2x.pdf here].

Revision as of 09:15, 1 August 2014

This page has not been completed. Parts may be missing or reorganized before completed. Information is provided as-is and may have errors.

This page will fill up with documentation for the USB communication with the Prizm. If you have any documentation or have played around with the USB communication for the Prizm, please discuss in the Talk:USB_Communication page. Thank you!

Protocol

The Prizm uses the MSD USB protocol for Drive mode, Screen Receive, and OS Updates (both modes). For the extra data, it uses UFI bulk-mode data methods.

MSD CBW Description

Bit 7 6 5 4 3 2 1 0
0-3 bCBWSignature
4-7 dCBWTag
8-11 dCBWDataTransferLength
12 bmCBWFlags
13 Reserved (0) bCBWLUN
14 Reserved (0) bCBWCBLength
15-30 CBWCB
  • dCBWSignature - Always 0x43425355 in little endian. Indicates a CBW.
  • dCBWTag - A 4 byte tag sent by the host, echoed back by the peripheral in a CSW.
  • dCBWDataTransferLength - Amount of bytes, in little endian, expected to be sent/received on a bulk pipe directly after sending the packet.
  • bmCBWFlags - 0x00 if sending host to device, 0x80 if device to host. Ignored if dCBWDataTransferLength is 0.
  • bCBWLUN - Set to 0.
  • bCBWCBLength - Length of usable data in CBWCB. Doesn't mean packet size is different!
  • CBWCB - Command block to be executed. For the Prizm, this is a UFI command block.

MSD CSW Description

Bit 7 6 5 4 3 2 1 0
0-3 dCSWSignature
4-7 dCSWTag
8-11 dCSWDataResidue
12 bCSWStatus
  • dCSWSignature - Always 0x53425355 in little endian. Indicates a CSW.
  • dCSWTag - Set to the dCBWTag of the received CBW.
  • dCSWDataResidue - When receiving data from the host, this is the difference between the amount of data expected in dCBWDataTransferLength and the actual amount of data processed. For sending, it is the difference between dCBWDataTransferLength and actual bytes sent.
  • bCSWStatus - Indicates the success or failure. Responses are below
Value Description
0x00 Command Passed
0x01 Command Failed
0x02 Phase Error
0x03 and 0x04 Reserved (Obsolete)
0x05 to 0xFF Reserved

If there is an error, you should perform a phase recovery.

MSD UFI Command Block Description

Bit 7 6 5 4 3 2 1 0
0 Operation Code
1 Logic Unit Number Reserved
2 (MSB) Logical Block Address
3
4
5 (LSB)
6 Reserved
7 (MSB) Transfer or Parameter list or Allocation Length (usually allocation length)
8 (LSB)
9 Reserved
10 Reserved
11 Reserved

MSD UFI Extended Command Block Description

Bit 7 6 5 4 3 2 1 0
0 Operation Code
1 Logic Unit Number Reserved
2 (MSB) Logical Block Address
3
4
5 (LSB)
6 (MSB) Transfer or Parameter list or Allocation Length (usually allocation length)
7
8
9 (LSB)
10 Reserved
11 Reserved

Prizm UFI Commands

ID Name Parameters Returns Comments
0xC0 Poll todo The prizm returns a 0xD0 response. Todo. Basically used to see if the Prizm is done processing the last sent data and is ready for more, and also checks to see if the Prizm wants to send something.

0xC0

Since the peripheral cannot initiate a data send on its own, the Prizm gets polled constantly to check for any activity. Here is the packet layout:

C0

Custom return data:

D0 00 00 00 00 00 00 SS SS 00 AA AA 00 00 00 00

  • SS SS - Amount of bytes as big endian that the Prizm wants to send
  • AA AA - Activity status of the Prizm. If value is not 10 00, then the Prizm is busy and cannot accept more data.

0xC1

Receives data. Should be sent if 0xC0 command revealed that the Prizm wants to send stuff. Syntax:

C1 00 00 00 00 00 SS SS

  • SS SS - Amount of bytes to be sent.

Once this is sent, the Prizm sends raw data.

0xC2

This command is used to send raw data to the Prizm. It seems the first byte of the raw data is not part of the data. The raw data usually is made up of character-encoded hex at the start. Command syntax:

C2 00 00 00 00 00 SS SS

  • SS SS - Amount of bytes to be sent.

Once this is sent, send the raw data directly after. Poll before sending more.

Protocol 7

Protocol 7 is the method for communicating to Casio calcs over IO or USB. The commands are sent in special command packets sent to the prizm as raw data after sending a 0xC2 command as an MSD UFI command. Confusing? Indeed. Below is the table showing you how the raw data sent to the Prizm from the 0xC2 UFI commands is read:

Byte Field Name Desciption Values
1 Type The basic purpose of the packet 0x00 to 0x1F
2 Subtype The specific function of the packet "00" to "57"
1 Extended Decides if data size and data field follow '0' - no; '1' - yes
(4, if extended) Data size Size of data field "0000" to "FFFF"
(n, if extended) Data Additional data related to packet function
2 Checksum Checksum for integrity check "00" to "FF"

The protocol on the Prizm is not exposed in all modes. Currently, USB Drive mode ignores Protocol 7 packets, but not the UFI packets. In screen receiver, there is a role swap and the packet structure is different. The only mode known to follow this is OS Update mode.

Credits

BrandonW
Simon Lother and Andreas Bertheussen for Protocol 7 info. PDF released under Attribution-NonCommercial-NoDerivs 3.0 Unported (CC BY-NC-ND 3.0) license, located here.