Difference between revisions of "Talk:83Plus:OS:84 Plus USB Information"
From WikiTI
(usb8x 0.09 updates) |
|||
| (65 intermediate revisions by 7 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | This page was split since it was getting large; see also the [[Talk:83Plus:OS:84_Plus_USB_Information/1|second page]]. | |
| − | : | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | == Currently unresearched ports == | |
| − | + | There are some ports whose function which we haven't yet agreed on, but I thought I'd compile a list of ports that neither of us have touched yet: | |
| − | + | * 81: This I/O port is used extensively on the 84P. | |
| − | + | * 8B: This output port is used extensively on the 84P. | |
| − | + | **On Titanium, 0x37 is written to this port in some code which disables all the pipes (which may be related to OTG's HNP). Also 0xF7 is written just after a loop which waits for bit 5 of port 81 to be cleared, at the beginning of the code to setup as host. These are the only 2 uses. | |
| − | + | * 92: This seems to be another setup port. It may have something to do with interrupts. | |
| − | + | * 95: In similar fashion to the other ports in this range, this is probably the incoming pipe version of port 92. | |
| − | + | * 9C - 9F: These ports are not used at all in the OS, and I would have just ignored them altogether, except the port monitor caught the value of 9F changing from 00 to 66 at some point during the USB communications. It's possible this is just junk data though. | |
| − | + | ||
| − | : | + | |
| − | : | + | |
| − | + | Then there are the lower ports on the 84P, which I don't know, but am guessing are different on the 89t, since I haven't heard anything about them: | |
| + | * 39: Various bits are either set or reset on this port. | ||
| + | * 3A: Various bits are set and reset on this port, but bit 3 is checked and used to determine whether to output to port 4B, among other things. | ||
| + | **Port 3A is never used on Titanium. Port 4B is used only at reset time where it is initialized, and only if bit 4 of port 31 is not set (this bit is normally used to stall a pipe... But here the pipe is not selected with port 8E). | ||
| + | ***Oddly, the default state of port 3A seems to be 00 on the 84P, and 0F on the 84P SE. I can't imagine what SE vs regular would have to do with USB though, so maybe there's something I'm missing. ----- After finding some more pwople with 84's, I've changed my mind. It seems that boot version 1.00 the port is 0F, and boot version 1.02 the port is 00. I'd like to look at the boot code for both of those to see the differences, but I'm going to put that on the back burner for the moment. | ||
| + | * 4A: This output port is only sent a value of 20 by the OS. | ||
| + | **Initialized also with 0x20 at reset time on Titanium. | ||
| + | * 4B: This output port is sent a value of 0 or 20 by the OS. | ||
| + | * 4F: Some weird bit sets and resets are in some circumstances done during the host's device init routine. | ||
| + | * 50: A value of 27 goes out this port during the same init code as descrbied in 4F above. | ||
| + | **Ports 4F and 50 are never used on Titanium. | ||
| + | * 54: various values are outputted, or bit 0 is set, on this port. | ||
| + | **On Titanium: I am pretty sure this port has something to do with OTG's HNP. | ||
| + | * 57: I/O port. No clue. | ||
| + | * 5A: A value of 1 is sent to this port during E00F setup. | ||
| + | **Same on Titanium but for device E00E. Some pieces of code check if this port has a value of 1: trap #4 (the hardware trap to shutdown the calc), the high-level function called "USBCheckReceived" by Kevin Kofler used during file transfers (it quits if it is 1: no transfers if we are configured to used the adapter), the ROM Call EV_getc (which calls a routine that checks if the device has been unplugged, with 56:5), and the USB interrupt, which calls the same routine as EV_getc instead of the standard handler. | ||
| − | + | ...These lower ports are especially odd because many of them are used very few times, or just once, in the OS. Does the 89T have anything that might resemble these? --[[User:Dan Englender|Dan Englender]] 00:52, 10 Jul 2005 (PDT) | |
| − | + | I suspect some missing initializations on Titanium that do exist on 84P to be due to a different interpretation of the USB controller's datasheet by the 2 teams of developpers. --[[User:ExtendeD|ExtendeD]] 03:56, 10 Jul 2005 (PDT) | |
| − | + | ||
| − | + | :So the 84+ and 89T use the same USB controller (yes, that's blatantly obvious, but we'd better actually put it in writing for inquiring minds. Also, I needed an excuse to bulletize ExtendeD's additions). --[[User:AndyJ|AndyJ]] 08:44, 10 Jul 2005 (PDT) | |
| − | + | == HNP == | |
| − | + | (lets start in a new section, there will be many things to talk about) | |
| − | + | ||
| − | + | ||
| − | : | + | Before a transmission between 2 Titaniums, the sending calculator first tries to become host: it tests if it is a A-device or B-device according to the plug inserted. If it is a B-device, it tries to become host with HNP. If it is a A-device, it tries to configure itself as a host (and perhaps many other things, the state diagram is as complicated as the one for a B-device). I don't know exactly what the receiving calculator do, but it also calls the routine for a A-device. I suspect the calculators both to try to become host: the first calculator to achieve this will be the host. Then come the bulk transfers. |
| − | : | + | So we have: |
| + | *a state variable, that can get Ax and Bx values (Ax states may be for a A-device, Bx for a B-device). You can find an out-of-date global state diagram on my blog, search 'USB States' [http://www.yaronet.com/blogs/blog.php?id=176] (2 detailed and up-to-date diagrams are currently in paper form...). There is a routine for a A-device to become host (which try to move from state A0 to state A4), and a routine for a B-device to become host (states B0 to B5). | ||
| + | *a function to move to a new state, that dispatches to handlers (one per state) that set the new state and perform port writtings. | ||
| + | *a routine which check for incoming events on the bus, called by the 2 previous routines (A-device and B-device), and also called by the interrupt handler, and changes the current state according to the events read on different ports. | ||
| + | In the 2 state diagrams (for a A-device and a B-device), there are ports modifications and tests everywhere as actions and transitions. Also some timers and loops are used (loops for 1 to 3 ms waitings, timers for 100ms to 1s timeouts). I am using the state diagrams at the end of the OTG spec, and this Powerpoint presentation by a guy from Cypress that details these complicated diagrams [http://www.usb.org/developers/presentations/pres0602/lane_hauck.pdf]. | ||
| − | :: | + | It's past midnight in France, and I am tired... Perhaps I will convert tomorrow my paper diagrams to Visio ones, it will be easier to work with this as a reference for the Titanium's workflow. --[[User:ExtendeD|ExtendeD]] 15:20, 10 Jul 2005 (PDT) |
| + | : OK, let me put what I have so far. During the device initialization, if the port 4D reports that a B cable is connected, it will fork to the HNP routine. This routine plays with ports 4C, 5B, 80, 81, 8B, and 8F (and possibly others if 3,3A is set). There are a bunch of loops and waits in here too, but after that routine is done, it outputs 90 to port 57, and then just continues along the USB initialization as if it were host. | ||
| + | :: ''but after that routine is done, it outputs 90 to port 57, and then just continues along the USB initialization as if it were host.'' I have this in my diagram (states B4 and B5). --[[User:ExtendeD|ExtendeD]] 03:51, 11 Jul 2005 (PDT) | ||
| + | : On the A-side, it seems like bit 0 of port 55 reset in the interrupt indicates an HNP request. I can't really tell from the port outputs, but it's the only interrupt request that seems unique to this process, so I guess it must be it. Depending on the current memory state, the code might output to port 4C, and will output some (or various) values to port 57. It looks like port 57 might be some kind the control port for these kinds of settings? | ||
| + | :: On Titanium, 55:0 is never used (only bit 2 and 4, as you have documented them) --[[User:ExtendeD|ExtendeD]] 03:51, 11 Jul 2005 (PDT) | ||
| + | :On the A-side, during initialization port 8F first reports the normal host setting, and then later changes to reflect HNP if it is active. This seems to agree with the state diagrams for HNP. | ||
| + | ::I have just finished the Visio for the state diagram of the B-device. Here it is in .vsd [http://membres.lycos.fr/extended/usb/b_device_hnp.zip] and in PNG [http://membres.lycos.fr/extended/usb/b_device_hnp.png] (use this link [http://membres.lycos.fr/extended/usb/] if you have problems with the referrer using IE). --[[User:ExtendeD|ExtendeD]] 03:00, 11 Jul 2005 (PDT) | ||
| − | |||
| − | + | The state diagram is very nice. Unfortunately I wasn't able to map what I read in the diagram to what I saw going on on the 84P. So instead I took a little break from the research stuff and worked some more on the driver today. I got bulk I/O working, and wrote another demo: this time with the silverlink. In case anyone had been sitting up at night wondering, using the standard TI serial routines, the calculator can transmit data to itself at ~2.3 KB/s. --[[User:Dan Englender|Dan Englender]] 23:25, 11 Jul 2005 (PDT) | |
| − | + | ||
| − | Dan, | + | == Meta == |
| − | :I | + | Um... Dan, did you intend to revert a bunch of earlier changes [http://wikiti.denglend.net/index.php?title=83Plus:OS:84_Plus_USB_Information&curid=1525&diff=1790&oldid=1789&rcid=2571 here] ? --[[User:FloppusMaximus|FloppusMaximus]] 17:40, 13 Jul 2005 (PDT) |
| + | :No, I didn't. I've been having a lot of caching problems (I keep getting old copies of pages) and I have no idea why. I guess that was an example. I'll change them back soon --[[User:Dan Englender|Dan Englender]] 19:05, 13 Jul 2005 (PDT) ----- Fixed. Thanks for pointing that out. --[[User:Dan Englender|Dan Englender]] 19:25, 13 Jul 2005 (PDT) | ||
| − | + | ||
| + | == 0.09 Updates == | ||
| + | I've been working on version 0.09 of usb8x. The version in the CVS is relatively stable, but I'll be posting an official release sometime soon. A couple things to mention: | ||
| + | * In case anyone was wondering, the hardware allows you to setup the same pipe/endpoint number for both IN and OUT transfer. | ||
| + | * The issue with a lot of flash drives not working (i.e. sandisk cruzer) was a bug in usb8x caused by #1. It's been fixed. | ||
| + | * The new version includes a compile-time option for logging lots of internal state data to one of the extra RAM pages. Hopefully this will be useful for debugging new drivers. | ||
| + | --[[User:Dan Englender|Dan Englender]] 00:41, 3 June 2006 (PDT) | ||
Latest revision as of 23:41, 2 June 2006
This page was split since it was getting large; see also the second page.
Currently unresearched ports
There are some ports whose function which we haven't yet agreed on, but I thought I'd compile a list of ports that neither of us have touched yet:
- 81: This I/O port is used extensively on the 84P.
- 8B: This output port is used extensively on the 84P.
- On Titanium, 0x37 is written to this port in some code which disables all the pipes (which may be related to OTG's HNP). Also 0xF7 is written just after a loop which waits for bit 5 of port 81 to be cleared, at the beginning of the code to setup as host. These are the only 2 uses.
- 92: This seems to be another setup port. It may have something to do with interrupts.
- 95: In similar fashion to the other ports in this range, this is probably the incoming pipe version of port 92.
- 9C - 9F: These ports are not used at all in the OS, and I would have just ignored them altogether, except the port monitor caught the value of 9F changing from 00 to 66 at some point during the USB communications. It's possible this is just junk data though.
Then there are the lower ports on the 84P, which I don't know, but am guessing are different on the 89t, since I haven't heard anything about them:
- 39: Various bits are either set or reset on this port.
- 3A: Various bits are set and reset on this port, but bit 3 is checked and used to determine whether to output to port 4B, among other things.
- Port 3A is never used on Titanium. Port 4B is used only at reset time where it is initialized, and only if bit 4 of port 31 is not set (this bit is normally used to stall a pipe... But here the pipe is not selected with port 8E).
- Oddly, the default state of port 3A seems to be 00 on the 84P, and 0F on the 84P SE. I can't imagine what SE vs regular would have to do with USB though, so maybe there's something I'm missing. ----- After finding some more pwople with 84's, I've changed my mind. It seems that boot version 1.00 the port is 0F, and boot version 1.02 the port is 00. I'd like to look at the boot code for both of those to see the differences, but I'm going to put that on the back burner for the moment.
- Port 3A is never used on Titanium. Port 4B is used only at reset time where it is initialized, and only if bit 4 of port 31 is not set (this bit is normally used to stall a pipe... But here the pipe is not selected with port 8E).
- 4A: This output port is only sent a value of 20 by the OS.
- Initialized also with 0x20 at reset time on Titanium.
- 4B: This output port is sent a value of 0 or 20 by the OS.
- 4F: Some weird bit sets and resets are in some circumstances done during the host's device init routine.
- 50: A value of 27 goes out this port during the same init code as descrbied in 4F above.
- Ports 4F and 50 are never used on Titanium.
- 54: various values are outputted, or bit 0 is set, on this port.
- On Titanium: I am pretty sure this port has something to do with OTG's HNP.
- 57: I/O port. No clue.
- 5A: A value of 1 is sent to this port during E00F setup.
- Same on Titanium but for device E00E. Some pieces of code check if this port has a value of 1: trap #4 (the hardware trap to shutdown the calc), the high-level function called "USBCheckReceived" by Kevin Kofler used during file transfers (it quits if it is 1: no transfers if we are configured to used the adapter), the ROM Call EV_getc (which calls a routine that checks if the device has been unplugged, with 56:5), and the USB interrupt, which calls the same routine as EV_getc instead of the standard handler.
...These lower ports are especially odd because many of them are used very few times, or just once, in the OS. Does the 89T have anything that might resemble these? --Dan Englender 00:52, 10 Jul 2005 (PDT)
I suspect some missing initializations on Titanium that do exist on 84P to be due to a different interpretation of the USB controller's datasheet by the 2 teams of developpers. --ExtendeD 03:56, 10 Jul 2005 (PDT)
- So the 84+ and 89T use the same USB controller (yes, that's blatantly obvious, but we'd better actually put it in writing for inquiring minds. Also, I needed an excuse to bulletize ExtendeD's additions). --AndyJ 08:44, 10 Jul 2005 (PDT)
HNP
(lets start in a new section, there will be many things to talk about)
Before a transmission between 2 Titaniums, the sending calculator first tries to become host: it tests if it is a A-device or B-device according to the plug inserted. If it is a B-device, it tries to become host with HNP. If it is a A-device, it tries to configure itself as a host (and perhaps many other things, the state diagram is as complicated as the one for a B-device). I don't know exactly what the receiving calculator do, but it also calls the routine for a A-device. I suspect the calculators both to try to become host: the first calculator to achieve this will be the host. Then come the bulk transfers.
So we have:
- a state variable, that can get Ax and Bx values (Ax states may be for a A-device, Bx for a B-device). You can find an out-of-date global state diagram on my blog, search 'USB States' [1] (2 detailed and up-to-date diagrams are currently in paper form...). There is a routine for a A-device to become host (which try to move from state A0 to state A4), and a routine for a B-device to become host (states B0 to B5).
- a function to move to a new state, that dispatches to handlers (one per state) that set the new state and perform port writtings.
- a routine which check for incoming events on the bus, called by the 2 previous routines (A-device and B-device), and also called by the interrupt handler, and changes the current state according to the events read on different ports.
In the 2 state diagrams (for a A-device and a B-device), there are ports modifications and tests everywhere as actions and transitions. Also some timers and loops are used (loops for 1 to 3 ms waitings, timers for 100ms to 1s timeouts). I am using the state diagrams at the end of the OTG spec, and this Powerpoint presentation by a guy from Cypress that details these complicated diagrams [2].
It's past midnight in France, and I am tired... Perhaps I will convert tomorrow my paper diagrams to Visio ones, it will be easier to work with this as a reference for the Titanium's workflow. --ExtendeD 15:20, 10 Jul 2005 (PDT)
- OK, let me put what I have so far. During the device initialization, if the port 4D reports that a B cable is connected, it will fork to the HNP routine. This routine plays with ports 4C, 5B, 80, 81, 8B, and 8F (and possibly others if 3,3A is set). There are a bunch of loops and waits in here too, but after that routine is done, it outputs 90 to port 57, and then just continues along the USB initialization as if it were host.
- but after that routine is done, it outputs 90 to port 57, and then just continues along the USB initialization as if it were host. I have this in my diagram (states B4 and B5). --ExtendeD 03:51, 11 Jul 2005 (PDT)
- On the A-side, it seems like bit 0 of port 55 reset in the interrupt indicates an HNP request. I can't really tell from the port outputs, but it's the only interrupt request that seems unique to this process, so I guess it must be it. Depending on the current memory state, the code might output to port 4C, and will output some (or various) values to port 57. It looks like port 57 might be some kind the control port for these kinds of settings?
- On Titanium, 55:0 is never used (only bit 2 and 4, as you have documented them) --ExtendeD 03:51, 11 Jul 2005 (PDT)
- On the A-side, during initialization port 8F first reports the normal host setting, and then later changes to reflect HNP if it is active. This seems to agree with the state diagrams for HNP.
The state diagram is very nice. Unfortunately I wasn't able to map what I read in the diagram to what I saw going on on the 84P. So instead I took a little break from the research stuff and worked some more on the driver today. I got bulk I/O working, and wrote another demo: this time with the silverlink. In case anyone had been sitting up at night wondering, using the standard TI serial routines, the calculator can transmit data to itself at ~2.3 KB/s. --Dan Englender 23:25, 11 Jul 2005 (PDT)
Meta
Um... Dan, did you intend to revert a bunch of earlier changes here ? --FloppusMaximus 17:40, 13 Jul 2005 (PDT)
- No, I didn't. I've been having a lot of caching problems (I keep getting old copies of pages) and I have no idea why. I guess that was an example. I'll change them back soon --Dan Englender 19:05, 13 Jul 2005 (PDT) ----- Fixed. Thanks for pointing that out. --Dan Englender 19:25, 13 Jul 2005 (PDT)
0.09 Updates
I've been working on version 0.09 of usb8x. The version in the CVS is relatively stable, but I'll be posting an official release sometime soon. A couple things to mention:
- In case anyone was wondering, the hardware allows you to setup the same pipe/endpoint number for both IN and OUT transfer.
- The issue with a lot of flash drives not working (i.e. sandisk cruzer) was a bug in usb8x caused by #1. It's been fixed.
- The new version includes a compile-time option for logging lots of internal state data to one of the extra RAM pages. Hopefully this will be useful for debugging new drivers.
--Dan Englender 00:41, 3 June 2006 (PDT)
![[4]](http://membres.lycos.fr/extended/usb/b_device_hnp.png){kind=link}