• Status Closed
  • Percent Complete
  • Task Type Patches
  • Category Drivers
  • Assigned To No-one
  • Operating System Sansa AMSv2
  • Severity High
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by pamaury - 2010-10-10
Last edited by funman - 2011-12-13

FS#11664 - Workaround for usb random failures on amsv2.

This patch is a possible workaround the usb random failures on amsv2 (mainly clip+).

The test procedure is as follow:
1) Apply the first patch [as3525v2-enable-usb] (to svn head)
2) Try to plug/unplug the player several times (10 or 20 times or even more if you want) and note how many times it fails to work (no mass storage device detected, doesn't mount)
3) Apply the second patch [as3525v2-usb] (to svn head)
4) Repeat step 2)

The expected result is >0 failures in 2) and 0 failures in 4).
All amsv2 devices are interesting:
- fuzev2 to check regression
- clip+ to check improvement

Comments on the patch are welcome.

Closed by  funman
2011-12-13 20:45
Reason for closing:  Out of Date
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

USB is now enabled.

If there are still bugs they should probably discussed somewhere else.

Mixed results on my clip+.

With the first patch it fails sometimes (as expected).

With the second, doesn't fail as much but three times it "froze", as in it's stuck in main menu (which is weird) or the "usb cable screen". The menu cannot be navigated. Kernel says "device not accepting address 19, error -32". The player (and its USB, too) is then unusable until I power off the player forcefully (holding power button for a while). Rockbox wasn't fully dead though. The display shuts down after a while and a button click lights it again (when unplugged).

[256687.316571] usb 2-1.3.1: new low speed USB device using ehci_hcd and address 19
[256687.391694] usb 2-1.3.1: device descriptor read/64, error -32
[256687.556558] usb 2-1.3.1: device descriptor read/64, error -32
[256687.730427] usb 2-1.3.1: new low speed USB device using ehci_hcd and address 20
[256687.805363] usb 2-1.3.1: device descriptor read/64, error -32
[256687.981411] usb 2-1.3.1: device descriptor read/64, error -32
[256688.155370] usb 2-1.3.1: new low speed USB device using ehci_hcd and address 21
[256688.557108] usb 2-1.3.1: device not accepting address 21, error -32
[256688.630555] usb 2-1.3.1: new low speed USB device using ehci_hcd and address 22
[256689.033079] usb 2-1.3.1: device not accepting address 22, error -32
[256689.033460] hub 2-1.3:1.0: unable to enumerate USB device on port 1

On some plug-in attempts it says "low speed", on some "high speed", I'm confused.

Can't reproduce it reliably. It doesn't happen very often.

FuzeV2, latest SVN + this patch + changes in config/SansaFuzeV2.h to enable RB USB. Host system is Win7.

Without patch: fails most of the times.
With patch: 100% working :-D Plugged in/out at least ten times, I didn't experience any lockup and the player always got recognized. Had a glitch where it said that the device connected in 1.1 mode, but OF does that too sometimes, I suspect a dodgy cable.

Here also FuzeV2 with the latest SVN + the 2nd patch + changes in config/SansaFuzeV2.h.
but it doesn't work for me, at the moment of plugin in the USB cable in the Computer (Host: Win7) I get:

usb-drv: wrong architecture (0)

Would it be possible to post a diff file were the needed changes in config/SansaFuzeV2.h are also included?

The changes for fuzev2 should be the same as for clip+ expect that the file to change is sansfuzev2.h instead of sansclip+.
I attached a modified version of the diff for fuzev2 but I can't test it myself. Hope it helps.

Building the Bootloader fails after applying this patch.

I don't know much about the bootloader build but looking at the errors, it seems that usb.c is not compiled in. For example, two errors come from usb_core.c which I did not modify so perhaps there is something wrong which the building options or something like that.

Fusev2, svn head, second patch applied.

Great patch! Under normal circumstances USB works perfectly. However, if I use 'charge mode' (ie hold select while plugging in) the host (Ubuntu 10.10) then gives a kernel error every time I plug the player in until I reboot the PC. The bootloader also fails to build for me, with the same errors as above.

OK, so it's not quite flawless yet - the kernel error I got before has started appearing even when I haven't used 'charge mode':

[22791.125982] ehci_hcd 0000:00:1a.7: port 4 reset error -110
[22791.141985] ehci_hcd 0000:00:1a.7: port 4 reset error -110
[22791.141992] hub 1-0:1.0: hub_port_status failed (err = -32)

Thanks for testing.
The point of the patch is not to eliminate all kernel errors because it's impossible to do it this way. The point of this patch is to achieve a working state every time you plug the device, even if the device goes through an unstable state and kernel emits errors. In your case, my question is: after these errors, is the device eventually working or not as a mass storage ?

It seems that this error is pretty common - after following the procedure given at it seems to work OK. Maybe then it's more of an OS issue than an issue with your patch?

It's not that simple. To put it simply, we know the usb code for amsv2 has a problem which has probably to do with initialization. Thus, it may happen that the controller misbehave and thus produces errors that the kernel reports. The purpose of this patch is to kind of hard reset the controller when this situation arises. If there weren't such errors, this patch would no be necessary :)

First patch gives intermittent success on my Clip+.

Second patch works consistently, however my WinXP SP3 box sometimes gives a message saying I should connect to a High-Speed USB port. I get no such message using the OF.
I did get a panic, something about the USB driver waiting for an ACK when something else happened. I haven't reproduced it.

I have an old box running Ubuntu 10.04, I'll try to test on it tomorrow.

The 2nd patch also in the same manner as in the previous post on the fuze2.

I can reproduce the USB 1.1 issue most of the times with the following procedure:

1. turn the fuze2 on, connect to the host (win7) → USB 2.0
2. disconnect
3. connect again to the host → USB 1.1
4. disconnecting and connecting without shutting down the fuze gives me after the first time always USB 1.1
5. shutdown and turn the fuze on (reboot)
6. connect to the host → USB 2.0

It also happend a very few times (aprox. 1 in 15 reboots) that I can connect and disconnect without rebooting the fuze and still getting USB 2.0 everytime.

On WinXP I get the same results as Daniel WRT to USB version/speed with my Clip+

On Linux I get consistent USB 2.0 High Speed connections.

Note that my Linux box has a USB PCI card inserted with USB 2.0 ports. The build-in controller is only 1.1.

Interestingly, it seems that linux behaves differently from Windows.
On Linux I also get consistent high speed connections. I didn't check with window (nor XP nor Seven) but apparently Windows is screwing up with usb one more time.

Seems to work fine with clipv2 on Linux 2.6.35.

What about USB HID mode?

I can confirm that this seems to make USB work reliably in high-speed mode on the ClipV2 (with the obvious added change to sansaclipv2.h; see attachment).

Oops, I meant to add that this is with a Linux host.

sian commented on 2010-11-19 00:10

just had to disconectthe battery of my friends ipod classic 5g as it wouldnt disconnect off usb .we lost the os completely its now asking for itunes to fix it.

but we did that already.


im new and im deprate to get this fixed

This fix does not target ipods, it's only for amsv2 based players, as stated (clip+,fuzev2).

I have no idea if HID is working but I think during my last try it didn't work.

Since using Rockbox-native USB slave mode on my Sansa ClipV2 through this patch, I've had regular filesystem corruption. See  FS#11774  for a possible fix.

Since  FS#11774  was committed can this in-turn be committed (USB enabled in AMSv2) or does more testing need to be done? I have a FuzeV2 which I will use to test if needed

No decision has been taken regarding this patch. In particular, it seems to force full speed mode with windows which us not great.

Is there a way to prevent the original firmware being loaded when USB is plugged into my Fuzev2? I can't figure out how to code it myself, and with this patch I want rockbox to boot every time :)

jon commented on 2010-12-14 16:22

Sansa Fuse v2 8G
Not ideal test conditions: I tested 2) on a machine properly, 20 insertion attempts, one failure. A handful (~25%?) of USB 1 negotiations.

Unfortunately after that the machine I was using died.

Since then I've used d) for a few weeks, no problems whatsoever across several computers. At least 20 attempts.

Kyle commented on 2010-12-17 05:30

Clip+ 8GB, Ubuntu 10.10. Working flawlessly here. I only wish Rockbox would handle the USB connection if the player is turned off. At this point, the OF still handles USB if the player is powered off before plugging into either a computer or a charger, causing a bunch of unnecessary files and directories to be copied to the disk by the OF, and very long wait times before the player becomes usable again. This, however, is less related to the patch than it is to my complete unwillingness to even try to use the OF. So overall, this is a very good report on this patch. Please get it committed soon.

Drise commented on 2010-12-22 07:35

Has there been any recent updates on this patch's status?

No, I'll discuss with the others to see if I can commit it.

The patch wouldn't apply for me with r28903, so bertrik updated it a little. Attached is a copy.

The patch appeared to build successfully, but when I plugged in my Clip+, it failed to mount (Ubuntu 10.10 is the host OS) and the disk access light stayed on. Eventually I took a chance and disconnected the Clip+, but the disk icon remained on, and it was stuck on the USB screen. I had to force a power off, and am now scanning with fsck.vfat for filesystem damage. (There was no microSD inserted.)

Also attached is my kernel log from the time of the testing.

Kyle commented on 2010-12-26 22:40

I can confirm this behavior on my Clip+. The device freezes if no memory card is inserted before connecting to the computer or if I right-click the card's icon and choose eject. In order to get the player back to a usable state, I must force power off and restart. Everything works perfectly if a card is already inserted before connecting to the computer.

I had a similar result to Strife89 above. After applying either patch to my Fuze v2 it would freeze and not mount under Ubuntu 10.10. I didn't have a micro SD card to test so I cut out a micro SD card shaped piece of plastic from an old credit card and put it in the Fuze. I am able to mount my Fuze as a mass storage device successfully and reliably only with the dummy micro SD card inserted. Maybe there is a problem involving sd card detection code that needs to be fixed?

 FS#11877  may be related:

With USB enabled by this patch on my ClipV2, I still have recurring apparent filesystem corruption that goes away when I replug or reboot the player without fixing the detected corruption.

The pattern of corruption exposed over USB (single-byte corruption with the values 0x7d, 0x7e, 0xfd, or 0xfe, always appearing after pairs of valid 0x7d,0x7e or 0xfd,0xfe bytes) seems to point into USB's general direction: My googling indicates that at least 0x7d,0x7e are used as escape bytes in some low-level part of USB signaling.

MikeS commented on 2011-01-24 18:33

@Kyle: I really cannot hotplug a card at all on the Fuzev2. USB or not, it barely works.

MikeS commented on 2011-01-28 04:46

I placed a patch to help with the Micro SD inserts in USB into  FS#11877  that works alright for now on my v2 Fuze. Probably would have been more suitable here, but it's there instead! :P

i've been using this patch on my clip v2 for a good few weeks now with no real issues. occasionally windows won't recognise it first time when plugging in but a quick reboot of the device has usually fixed that. file transfers have been fine. anyway, i'm just posting to say r29154 has completely broken it. on the first connection attempt i got a data abort but didn't get to note down the details. after that, i've had the usb logo show but without the status bar so i know something is wrong. also the device is not recognised by windows at all. i've tried rebooting the device several times and even windows itself but no joy. i've since reversed just r29154 and it's working fine again.

MikeS commented on 2011-01-29 03:37

That certainly sounds severe for that one line and indicative of some other issue going on. My Fuzev2 seems to like it. To remove any doubt in my mind, did you revert _back_ to before r29154 or just revert the one change but otherwise use the latest SVN?

ETA: before

i'm using latest svn (29159) with just that one update reverted. i've just shifted 500mb+ of files each way and that was fine. i'll try applying 29154 again and see if i can get anymore useful information???

MikeS commented on 2011-01-29 04:18

Ok, good, the other stuff is ok then :). It could allow messages into the USB queue we don't want at certain times because it yields (don't know what though) or perhaps a stray transfer completion (just guessing here).

Just out of curiosity you could add:

if (usb_state == USB_EXTRACTED)

to the beginning of the USB_TRANSFER_COMPLETION case in usb_thread() in usb.c, with 29154 in place of course.

nope still no joy even with your modification. it's exactly the same as before.

just checking i put it in the right place??


    if (usb_state == USB_EXTRACTED)
              (struct usb_transfer_completion_event_data*);

#endif /* HAVE_USBSTACK */

one thing i forgot to mention previously and it's just happened again after re-applying 29154 and that is it's resetting USB mode in the OF back to "auto detect" when it was on MSC previously.

MikeS commented on 2011-01-29 06:11

Yep, it looks fine.

I tried to check if the driver exit function is called from an improper place for sleeping calls and didn't find anything so far. :\

Doing the disconnect is required but a couple other things might be needed as far as powering off the OTG. One thing you didn't mention is, besides 29154, has anything changed as far as connect reliablilty because for me on the fuze it never fails anymore except when XP starts leaking resources after lots of connect cycles, which happens with everything.

@anyone who knows: From where does knowledge of the other bits come in PCGCCTL? Bit 0 is all I find in the 6400 docs.

unfortunately, i've just had a connection failure. but that was after repeated attempts in a short space of time - not something i'd do usually. it certainly appears to happen less often. i'm using windows 7 x64 FWIW (although i've been building in vmware with ubuntu 10.10).

MikeS commented on 2011-01-29 12:46

I've had those, especially doing that, with every device, OF or not, mostly with Windows' refusal to connect sound, but not always.

One check: replace the sleep with udelay(1000000/20) which also works on fuze (sort of a klude fix if it works, but perhaps informative).

ETA: oh, and maybe post a copy of your setting config?

ah, the udelay change appears to be working - windows is now recognising my player. nice job. it's too late for me to test more thoroughly right now but i'll report back tomorrow.

just writing to confirm it's working fine. transfers are good and device recognition is much faster than it was before. thanks. (:

MikeS commented on 2011-02-02 05:00

That's quite interesting. It indicates some problem with sleeping, to me, so far at least. I'm thrilled but not entirely since that's a rather nasty long time for a thread to exclusively control the CPU– have to figure out what could be the problem with a sleep()…it will keep me awake at night. :\

ETA: Something with using the wait-for-interrupt instruction at that particular time maybe. ???

MikeS commented on 2011-02-02 05:10

One way to test (and thank you for doing so so far):

Instead of sleep() or udelay() try:

long tick = current_tick + HZ/20;
while (TIME_BEFORE(current_tick, tick))

If that works still works well, it strongly indicates an issue with sleeping the CPU core at that particular moment (which indicates a problem in general). If it doesn't work, something else is going on.

nope, that doesn't work.

usb-drv: disconnect

i also saw this on another attempt

Undefined instruction at 3008D594

MikeS commented on 2011-02-04 05:24

So, it's sort of like before. Hmmm. Ok, so something strange is afoot for sure.

Where is 3008D594 in your build? Could you attach the .map for that one?

ETA: try r29205 as is - there was a serious problem of double init

when you say attach the .map, i have no idea what you mean. :D

i just tried r29205 and i got the little sound as if a usb device had been connected and an "installing drivers" notification. but then i got a windows dialog to say it had failed.

I can confirm that something doesn't work with current SVN (I've tried r29205). I get strange SCSI errors when accessing my ClipV2 SD over USB on my Linux box:

Feb 4 09:24:36 machine kernel: [97521.845204] sd 17:0:0:0: [sdb] Unhandled sense code
Feb 4 09:24:36 machine kernel: [97521.845209] sd 17:0:0:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Feb 4 09:24:36 machine kernel: [97521.845213] sd 17:0:0:0: [sdb] Sense Key : Medium Error [current]
Feb 4 09:24:36 machine kernel: [97521.845218] sd 17:0:0:0: [sdb] Add. Sense: Unrecovered read error
Feb 4 09:24:36 machine kernel: [97521.845222] sd 17:0:0:0: [sdb] CDB: Read(10): 28 00 00 eb ef f8 00 00 01 00
Feb 4 09:24:36 machine kernel: [97521.845230] end_request: I/O error, dev sdb, sector 15462392
Feb 4 09:24:36 machine kernel: [97521.845234] Buffer I/O error on device sdb, logical block 1932799

And fsck.vfat says:

# fsck.vfat /dev/sdb
dosfsck 3.0.9, 31 Jan 2010, FAT32, LFN
Read 32 bytes at 7901134848:Input/output error

When I tried reenabling the USB hard-reset code in the workaround patch posted above (I've been successfully running without the hard-reset code for some time now), I also saw crashes similar Marc's.

All this does not occur with r29146 (or with the OF). I don't have time for a proper bisect at this moment, but will post my results when I do find the time.

OK, the bisect went faster than I thought. The bad commit is r29169 (jethead71: AMSv2 SD: Fix card insert lockups in USB mode.)

This usb bug is really strange, the fact it is somehow linked to to the SD code is weird. On my side, I never had problems with sd.

MikeS commented on 2011-02-04 17:50

It looks like an SD bug then because infinite loops should not be needed there to wait things out. You could increasing the try count when waiting for tran state, or, allow a full retry of the main card too.

I've noticed some weird depenedency between the FM and the USB. The FM register screen shows strange values while USB is connected even though radio is not enabled. The i2c code in tuner_init locks at boot as well if the cable is inserted.

BTW, wasn't that commit quite awhile ago in RB time? You hadn't updated?

MikeS commented on 2011-02-04 18:40

It's made with the build in the build directory with the main binary, called
However, not crashing might have brought it to sanity and is actually a step in the right direction.

I'm up for getting a v2 clip but I can't just buy it since I don't know what I'm getting and I already have v1. I could explore ideas in minutes or hours that otherwise take days or weeks of interrogation and testing.

when you originally asked for the .map i think i was running r29194 so i went back to that and of course used the 3 line code snippet in question. i tried it just now and got this error…

Data abort
at 30049FD8
FSR 0x8
(domain 0, fault 8)
address 0xE59F38D4

i've attached the .map (hopefully). if you want the .map from any other build just give me a shout. (i'm assuming it changes on every update/modification???) (303.8 KiB)
MikeS commented on 2011-02-05 20:20

It looks like It data aborted in switch_thread (very weird). Usually if that happens, it's being called in the wrong CPU state but who knows.


I doubt that V1 clips are still being sold. But if you want to increase the likelihood of getting a V2 Clip, you could go for the 4GB version. AFAIK there never was a 4GB ClipV1, and the 4GB version is only marginally more expensive than the 2GB one. Cheers!

MikeS commented on 2011-02-09 05:29

Good to know. Thanks for the tip :)

it's the 8GB that is v2 only. there are plenty of 4GB/v1 clips about so be careful.

for the record, using windows 7 usb 2.0 does work on the 'initial plug in'
1) Fresh turn on in rockbox, connect usb cable to windows 7 machine → usb 2.0 connection
2) disconnect usb cable
3) Reconnect usb cable → usb 1.1 connection ('this device could perform faster' message from windows)

I have a fuze v2 running r29143 with this patch along with the  FS#11304 

I also am using a Kensington micro SD HC card (8 gb) with the following markings

(it has the 4 with a circle, denoting the speed i believe)
C08G Japan
SDC4/8GB 03

sorry for the two posts, I couldnt edit…

The problems with r29169 should be fixed by r29625

Kyle commented on 2011-03-21 02:19

USB hasn't been working on my Clip+ at all since befor 29160, probably the 29154 mentioned in an earlier comment. Being visually impaired, it's impossible to read any error messages on the screen, but sometimes it lights up, apparently with an error, and pressing any button causes a reboot, and other times the screen goes completely dark and only a forced reset will allow the device to even power on. I now have to boot into the OF to connect it to the computer. r29625 still has this problem.

A further update: i am running r29635 with the following patches applied:
1)  FS#11304  - as3514-audio-hq.diff
2) - test_sd.patch
3) - 0001-Enable-Rockbox-USB-for-ClipV2.patch

my device: fuzev2 AMSv2 Varient 0
I am on windows 7 x64, usb 2.0 works after unplugging/replugging (no usb 1.1 issues)
8gb microsd card (works at 'boot' of rockbox)

as far as i can tell everything works! hope this helps someone

Same here!
r29644 with just the as3525v2-enable-usb.diff patch (changed properly to enable USB on fuze2) works like a charm.
I can plug and unplug and replug as much as I want without rebooting rockbox and no USB 1.1 issues.
Booting rockbox with a 8GB microsd card inserted and inserting, removing, reinserting it during USB mode also works without any issues as well.

As host I am running a 32bit Windows 7.

Drise commented on 2011-04-09 18:41

Well. In that case, can we have this added?

I simply applied the first patch (which does little more than enable USB) to build 29703 and put it on my FuzeV2 (hardware revision???). The first time I plugged in to my machine running WinXP Pro SP3, it just installed the rockbox devices and gave me complaint about how it could go faster in a USB 2.0 port. After unplugging-replugging, I received no such error. Moreover, the transfer speed seems to be normal (100MB write in 30sec - normal for internal memory). I can also read and write to my 32GB uSD without incident. I have not applied the test_sd patch, audio patch or any other patches. I'm going to try plugging it into a Win7 x64 box tonight.

Bad news with Clip+: I also only applied the first patch (let RB have USB control). It doesn't work with r229788 on WinXP SP3. I hear the connect sound on windows and the device manager shows two storage devices, but in explorer I don't see any drives.

Also dfkt over at ABI states, that it doesn't work at all for him with r28830 for clip+.

I did the same compile for my Fuze V2 and there it works perfectly!

Oops, sorry. Actually my compile was with r29726M-110417, not r229788 as stated above.

arnoc commented on 2011-05-02 10:09

My report is the same as Eli's, minus the usb1.1 issue (due to linux perhaps?). Using a brand-new refurb Fuze V2. Basically, USB2.0 works out-of-the-box once the stack is enabled in source. MicroSD is working as expected (replug etc)

Out of interest, I also compiled it with the second patch (as3525v2-usb.diff), which caused the device to freeze whenever USB was plugged in.

Running latest SVN with no additional patches.

The Fuze still boots into the OF, however, when plugged in after poweroff (though I suspect this is a simple bootloader setting and unrelated to the issue).

To confirm, USB2.0 mounting and file transfers works 100% of the time on SVN head Sansa Fuze v2 on both Linux and Windows 7 (unpatched, besides the patch to enable the USB stack in the first place).

tieum commented on 2011-05-07 12:57

I did some test with a Sansa Fuze v2

with as3525v2-enable-usb
- On Linux everything was fine
- On Win7the device was not recognized the very first time in Windows and the Fuze froze on the USB connected screen. All other times were OK. The only weird thing is that the SD card always shows up before internal memory (respectively drives E: and F:)

with as3525v2-usb
on both Linux and Win7 the Sansa crashes as soon as the USB cable is pugged in:
Data abort at 300051F24 FSR 0x8 (domain 0, fault 8) address 0x8B000034

Applied 2 builds with as3525v2-enable-usb, 1 for clip+ the other for Fuzev2. Both works flawlessy from the start with Ubuntu. For windows (XP & Vista) needed a few plugs/replugs to be recognised and for the driver to be installed. Had tried the FS-11664-Dec26-2010.diff patch last week and on the clip+ I was gettign errors similar to Matt M (Chesteta) on the Sunday, 13 March 2011, 18:37 GMT.

tieum commented on 2011-05-11 18:44

After using the first patch for some days I notice that after a certain time on and a certain number of plugging in, one of two things happens:

1) plugging the Fuze will briefly show the USB plug on the screen then go back to what it was displaying before. At that point you cannot read/write from the device but it will charge over the USB. You need to restart the Fuze to be able to read/write files.
2) the Fuze freezes

Is there anything that can be done when those happens to give some feedback to fix it?

Hello back,
in the hope that it will fix all the problems, I tried to rewrite the driver use the slave (aka PIO) mode of the controller. Since this driver doesn't use DMA at all, all the suspicious corruption bugs should be fixed. I provide here a patch against the trunk which also enables HID because it works with my Clip+. All comments are welcome especially since this is more or less a complete rewrite.

Hi pamaury,

Thanks for contributing the PIO-mode driver! This has great potential to get AMSv2 USB going. :)

I've been trying your patch on my Clip+ with two Linux hosts (with different kernel version), with mixed results. I get various read errors and resets. Sometimes, the host is unable to enumerate the USB devices. In three successive attempts to connect the Clip+ to the host (without rebooting in between), the HID worked two times, and the storage only one time. In each case, it took quite some time for the host to detect the USB devices.

(I've attached the Linux-kernel output from the three sessions.)

Another observation: On my Clip+'s display, Rockbox's USB-jack logo was shifted vertically into the yellow display area, presumably to make space for the USB-keypad mode line, which looked odd.

i have a clip v2 and clip+.

clip v2:
original "sansaclipv2.h" patch to enable usb on it's own does not work. adding the 2nd patch from the 1st post and this modification by MikeS works fine: new pio patch does not work at all. device not recognised by windows 7.

neither of the first 2 patches work. the 2nd patch corrupted some files and i had to run chkdsk to fix it.
new pio patch does not work at all. device not recognised by windows 7. tried multiple times with and without micro SDHC card.

I attempted to test pamaury's patch using r29914, but it failed to apply; hunk errors on every file it tried to patch.
(I took a shot at fixing it, but ultimately couldn't.)

That's strange, my patch was done against SVN and none of the touched file should have changed since then. Anyway, it's doesn't work apparently :(

With Windows 7 x64 the PIO mode patch apparently works fine, the first time had a problem installing the drivers but replugging the sansa solved it

Tested with a Fuze v2 with r29944, the only weird thing is that the MicroSD appears first instead of the internal memory

(Sorry for the english, it's not my native language)

I tested the PIO mode patch by trying the custom build by thegr8brain here:

It works really well with the Fuze v2 and Windows 7 64bit. I can plug/unplug continuously without any problems.

The only issue I see is if the Fuze v2 is turned OFF when plugging into USB or into a charger, the Fuze turns on and goes into the official firmware. OH NO!
With the Fuze v1 turned off, when plugging into USB or a charging cord, the Fuze v1 turns on and goes into the Rockbox firmware correctly. If I forget to turn on the fuze before plugging it in, I get to sit through a very long database refresh and a bunch of files are made I don't want. Hopefully this last thing can eventually be fixed.

So, the PIO mode patch for USB is almost perfect - at least for Windows 7 64bit. Thank you for making this work amaury pouly and thanks to thegr8brain for the custom build. Is the PIO mode patch good enough yet to fold into the official builds?

glued commented on 2011-08-20 18:43

I would happily use a fullspeed USB if a high mode isn't possible due to HW quirks/bugs that are only known to Sandisk.
Just not to see the [censored] OF and its [censored] auto folders ever again.
Pamaury, we all are extremely grateful for your countless efforts, you're the man, hats off.

Haven't tested the pio patch. The original patch works 100% with Ubuntu. Does have connection issues on Windows XP/Vista. Most times cannot connect at all.
My main machine is Ubuntu so I don't mind.

Seems to me the problem seems to be Windows host machines ?

I'm seeing an improvement on my clip+ with the attached patch. The patch does some pmu initialisation like the OF does.

awesome stuff. i finally have usb working on my clip+. it's recognised instantly on both windows 7 x64 and windows xp.

earlier in the thread, MikeS posted this hack: which i needed to get my clip v2 running. but now my clip+ won't run without this either which is making me think it's my pc that needs this fix and not the players. of course i'm speculating - i know nuffin. :D

are clipv2 and fuzev2 OF different?

I could have a try on fuzev2 but i am very lazy :)

If the fuzev2 OF init code is the same I can try on fuzev2 (I only have linux though)

MikeS commented on 2011-09-15 01:51

Which registers and what's it set? If it starts any power stuff, it might decrease batt life if not done just for when USB is plugged. Of couse, that's for later anyway. We might want to verify the setup for each device.

@Marc: what? you still need that ridiculous hack on another device? very odd.

yup, that hack is most definitely required for me. i had no joy whatsoever using any other combination of patches. i tried the pio mode on it's own and with the new pmu patch. nada. again i tried the original 1st patch+pmu and then the 2nd patch+pmu. finally i tried the 2nd patch, pmu patch and hack and it works.

what surprised me most is how quick it is. my clip v2 always took anything between a few and 10 seconds or more to initialise but this is instantaneous. it works very well for me. i did have one failure after many successive connection attempts but using the "troubleshoot" option found under "devices and printers" on the windows 7 start menu resolved it by re-scanning for drivers.

Could some one setup this patch for the Fuzev2; I would be willing to compile and test it, though I do not actually (currently) have issues connecting with USB using both the original patch, and the PIO mode patch (which I am currently using). I have windows 7 x64 and can test on 32 bit tomorrow if that would be necessary too.

I'm with Matt. I've got Win7 x64, OSX 10.6, and WinXP-32bit

e.g. the old patch, without PIO, works with builds from quite a while ago, but not with current builds.

@Mark Hewson,

which patches did you apply exacty? Which Patches are you referring to when talking about 1st and 2nd patch.. you meant the patches for pio and then pmu?
I ask because I'd like to see my clip+ running in USB mode too :)

the 2 patches that make up the first post of this task. unfortunately, it doesn't work for everyone. i uploaded a build for another person to test and it didn't work for them. i update to current SVN once a week and it's still working pretty well for me. occasionally it won't get recognised but using the "troubleshoot" feature i outlined above works every time.

when i get home later i can put up my complete diff if you want.

If you wouldn't mind Marc, I would like the .diff too.

The PMU patch has already been integrated into our codebase some time ago (a month or so?) so there's no use anymore trying to apply it.
There was some talk on IRC that a bugfix was done in the USB driver that the AMSv2 USB driver is based on, let me check if this bugfix also applies to the AMSv2 USB driver.

TheSeven's patch would translate to something like that (untested). Feel free to test all possible combination including:
- linux with and without sd inserted
- windows (xp and 7) with and without sd inserted

   usb.diff (2.3 KiB)

here's mine: all it consists of is the original patch from the opening post and this "kludge" as MikeS put it…

the patch also contains the code to enable the clip v2 as i own both.

   my.diff (2.4 KiB)

Using Marcs diff all 3 connect perfect to Windows XP. As fast as Ubuntu used to be using the old patch.
However with Marcs diff on ubuntu all 3 are slow to connect and the clip zip has the most problems being the slowest to be read.
So it looks to me like the problem is in firmware/target/arm/as3525/usb-drv-as3525.c.

All tests conducted with Sansa Fuzev2, Clip+ 8gb and Clip Zip 8gb with 32gb Micro SD.

make sure we align on cache line

No joy.

In Linux with Marcs patch, as soon as I connect the Clip+ to USB, the kernel starts spitting out this:

[1731019.646396] hub 2-1:1.0: unable to enumerate USB device on port 2
[1731019.885791] usb 2-1.2: new high speed USB device number 14 using ehci_hcd

continuously increasing the USB device number with or without 32gb sd card.

Added funmans 64byte buffer patch, but go the same result.

I seem like the USB stack is disconnection just to reconnect afterwards -

Updated to SVN r31161 and now my Fuze V2 will connect to Windows XP and Ubuntu no problems.

My Clip zip had some problems but after a few connects on a USB 1.1 port it seems to connect all the time now either on 1.1 or 2.0 usb ports. With or without SD Card.

The Clip+ is strange I can sometimes get it connected to XP, Everytime on Ubuntu. On XP tho when connection works it skips two drive letters i.e. Will Connect as H and M (J and K are taken) but it skips I and L to give the external sd card a letter. In this case L. Or sometimes External will get H and internal will get Maybe not related but thought I should mention it.

Stephen: do you mean, it works without patches? With Marc's diff? Or what?

Very weird I downloaded the SVN source again but it kept changes to my tree.
So I'm not sure which patches are in there. I even made svn-clean.

Before r31063 (funman patch) the Fuze2 was not connecting every time on a Win7 64bit machine, you had to try in some cases 2 or 3 times to get the drives recognized. Once recognized it was always USB 2.0. After r31063 this issue is gone. Now it recognizes the drives every time (and of course with USB2.0). I tested the last revision (r31161) also on a Linux 64bit system and also no issues there.

(Fuze2 r31161 and just the as3525v2-enable-usb.diff patch changed properly to enable USB on fuze2)

Seems r30163 - r30165 have gotten Fuzev2 USB stable? Once it gets enabled. No other patches needed.

As for the Clip+ and Clip Zip the hunt goes on.

esm commented on 2011-12-07 20:28

Sansa Fuze v2 here. Built & installed r31159 this morning + patched sansafuzev2.h + lineout patch. USB seems to be working, by which I mean: with Fuze powered on, I have connected the USB computer cable. My Gentoo box instantly recognizes the unit, all /var/log/messages output looks good, sdb and sdc1 (internal + MicroSD) mount and unmount properly, I am able to copy files to the mountpoint, and I am able to do this repeatedly. This is a use test, not a stress test, but so far it looks very good.

Just tested with r31178, this patch (w/all references to clip changed to fuzev2), and the lineout patch. On my desktop, USB works perfectly - it connects right away and both drives are mounted, but not on my laptop. Both are running Win7 x64, so it's quite odd…

On my laptop, my Fuze V2 is recognized successfully by Win7 x64, and drivers install fine (I tried this several times). However, neither the SD card nor the internal memory of the Fuze mount…at least, not for a few minutes. The old build of rockbox I was using (now 8 months old) worked fine. But I think there is something screwy with my machine, because my e280 v1, which has never had any problems connecting to USB, runs into the same 'wait a few minutes' situation. Accessing diskmgmt.msc or My Computer during time causes both of them to hang, both with the e280 and the Fuze.

Interestingly, when I hand-off the device to Lubuntu running in a VirtualBox VM, both the Fuze and the e280 are recognized instantly. I'm not really sure what to make of this or how to fix this very odd volume management issue, considering…

FuzeV2 so works in Snow Leopard 10.6.8 in VirtualBox.
I don't get it though - I have clearly experienced a regression here, from 29xxx builds (at least on this one host, my laptop). Has that much really changed in the usb stack?


Available keyboard shortcuts


Task Details

Task Editing