• Status Closed
  • Percent Complete
  • Task Type Patches
  • Category Drivers
  • Assigned To No-one
  • Operating System Sansa e200
  • Severity Low
  • Priority Very Low
  • Reported Version Version 3.1
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by ahellmann - 2009-03-15
Last edited by fg - 2009-03-17

FS#10026 - E200: Improve USB detection in WinXP

E200: Improve WinXP rockbox USB detection

With current SVN (in fact since the beginning of rockbox USB) I had the problem, that 7 out of 10 WinXP connections failed on the first try. A second try without reboot caused rockbox to freeze in the USB screen. If a connection was established (on the first try), I had no problems copying files from / to the sansa. After investigating the OF, I found the evil register, which seems to cause the problems.

In usb_init_device(void) (usb-fw-pp502x.c) I added the following register manipulation behind the udelay(100000) statement. This one liner solves the problems here and leads to the same behaviour as the OF. (no failed connections). After a short test I found no negative impact on other software parts.

XMB_RAM_CFG |= 0x47A; (added below udelay(100000); in usb-fw-pp502x.c

Closed by  fg
2009-03-17 20:29
Reason for closing:  Accepted
Additional comments about closing:  

Committed as r20344

In my OF disassemblies, this register set shortly after the OF is loaded in a "system_init" type function.
For the c200 & hdd1630 (pp5022) and the sa9200 (pp5024), it is XMB_RAM_CFG |= 0x4FA (⇐= NOT what Toni has above).
For the m:robe100 & tpj1022 (pp5020), it is XMB_RAM_CFG |= 0x400.

Of course there are also lots of other registers being manipulated in the section of code, some of which are clearly usb-related, and some which appear to be clock related (perhaps peripheral clocks). Also, I can't say that this register isn't touched in other parts of the OF.

NOTE: in the Rockbox PP5020 register definitions, we refer to XMB_RAM_CFG = 0x7000003c. However, according to the m:robe diagnostic menu, this register is misdefined. It defines XMB_NOR_CFG = 0x70000034 and XMB_RAM_CFG = 0x70000038.

Yes, you are right.

Initially the OF or-s with 0x4FA, but later on USB detection the register is first bic-ed with 0x85 then or-ed with 0x20, which gives effectively oring with 0x47A. The register shows 0x8005E6FA before and 0x8005E67A during USB connection in the OF. 0x8005E200 in rockbox before my mod.

I don't think, that the OF restores the old value after disconnection. I couldn't read the exact value, because the OF quickly reboots after disconnecting.

Toni, you are right ;)

Here's what the Philips SA9200 OF does:

There seems to be another error (I think Toni mentioned it in IRC):
usb-drv-arc.c:line 413 should be: while ((inl(0x70000028) & 0x80) == 0);

fg commented on 2009-03-16 20:35

I can't see any significant difference in the number of packet errors with or without these changes.

With the changes in the original post, I was able to transfer 35GB in Rockbox/SansaE280 without a disconnect on my problem machine. Without it transfer failed at ~1GB.

Michael, that sounds promising.
Frank, is there an easy way (either on sansa or in Windows/Linux) to detect packet errors?

fg commented on 2009-03-17 12:30

Toni: not really. They are handled transparently by the hardware, so software doesn't even know about them (unless there are too many in a short time, in which case the hardware does notify the software side).
I'm looking at them with a hardware tracer, so I can see things like retried packets reasonably easily.

The fact that  FS#10015  improves things does make me think that the problem is in talking to the controller on the sansa side, not actually on the wire ( FS#10015  shouldn't change anything on the wire, but it does seriously reduce the number of times we talk to the controller)

fg commented on 2009-03-17 20:22

This doesn't seem to hurt on ipod in any way, so I'm committing this.


Available keyboard shortcuts


Task Details

Task Editing