Mass storage device NAK'ing

[Prov]

Hi,

I'm in troubles with a mass storage device. I'm working on a microchip's PIC32, with their implementation of the USB stack (which I tweaked a little to have the highest possible speed).
The problem I'm facing is the following :
-the controller is a full speed one
-The usb stick exposes 2 interfaces (one full speed, and one high speed)
-In both (so especially in the high speed one), the endpoints define bInterval as 0 (so it shouldn't NAK when using high speed, so I can't see any reason why it would NAK when operating at full speed)
-If I spy USB data on windows (so connected using high speed), I can't see any symptoms of long periods of NAK's
-When I write to my USB stick with my PIC32 (using full speed so), the USB stick is sending me NAKs for very long periods of time (several hudreds of ms)

Those NAKS are obviously dropping the transfer speed (and it is causing some data loss), and don't sound very logic to me. I have no clue on how to investigate on the source of those NAKs, since I guess it's probably due to the stack implementation.....But I can't know where I could start investigations. Anyone would have a clue?

Thanks for reading, thanks even more for your answers

[Barry Twycross]

The first question is there any pattern to the NAKs? Do they happen every 512bytes? 4k, 64k? If you do see a pattern, what's significant about that in your design?

My device will NAK for 58ms every 4k. It writes to flash (NOR flash) in 4k blocks. When I time the flash writes, I find they take 58ms.

If you can't find any particular pattern the next thing to do would be to log writes to whichever register it is which changes the endpoint state (from NAK to active). See if you're just slow setting it, of if there's something else going on. Be careful that your logging doesn't cause delays in itself. I have a mechanism which logs the value written to a buffer along with the current frame number. Periodically, I log the information out the UART, which is slow, but I see the timestamps on the writes and can see what's going on.

[Prov]

Hi Barry,

Thanks for your answer,

First, as I said, the usb stick isn't supposed to NAK, imo, since it defines a high speed bInterval of 0.
Second, on windows, and so on high speed, it can write a 1Mo file in like...let's say 200/300ms. On my PIC, I can have a waiting time for more than 500ms for the same 1Mo File.
And thrid, I can't really see a pattern. The interval seems to be random, the NAKing time seems to be random too (actually, ATM I'm wondering if it could be related to memory address increasing, because as my file grows, the NAK time seem to grow)

[Barry Twycross]

Now I'm confused. Is your part the host or the device?

I wouldn't put any faith in a device declaring zero in the bulk bInterval. Everyone does that, and no one knows if they mean it. This would be particularly true of USB sticks.

[Prov]

My part is the host.
But I measured some NAKing time yesterday, and the device is often NAKing for like 400+ ms. This seems too long to me. Moreover, if I copy/paste a 1MB file on the USB stick from windows, the copy lasts for like....300ms. And I can see the 400ms NAK period of time if I create the file with my custom host on the same USB stick. I really have no clue on what could cause the stick sending NAKs for a so long period of time

[Jan Axelson]

See

http://www.lvr.com/forum/index.php?topic=173.msg611

[Barry Twycross]

My part is the host.

And the behavior is different between your host and a known good host?

I wouldn't be surprised by NAKing, flash devices will have to occasionally load balance, so they may be moving blocks around. This could cause seemingly random periods of NAKs.

And I really would put no faith in the bInterval of zero, that's bogus.

[Prov]

@Jan axelson :
I already had a look into the post you linked there, and indeed, the problem is that the device NAKs transfers....but for like 450ms. This seems pretty long to me, and I'm not sure this is due to the USB stick itself. I'd like to confirm this is a valid scenario, and not a problem inside the stack that makes the device NAKing for wierd reasons.

@Barry Twycross :
If I use a windows host, and make a simple copy/paste of a 1MB file, the total copy time is like 400ms. If I create the file using my own host, the copy lasts for the time it lasts, (it can't be the same, since my interface is full speed, it is necessary longer. Moreover, windows is making a better use of the bandwidth, using 64k per bulk write, while I'm using 4k), but I can see that the USB stick is NAKing for 450ms something like 3 times. I wrote the same amount on data, probably in the same adresses (I format the USB stick every time I want to make some measurements, to be in the same environment, and the FAT data seem to be the same, so the sectors I'm writing in are the same).
So for the exact same data, windows is writing the file in LESS time than the USB stick is sending NAKs when using my host.

[Jan Axelson]

Whether to NAK or not is totally a function of whether the device can accept or send data.

NAKing means the host is capable of faster transfers, but the device can't keep up.

In theory you could have a situation where the host sends < the endpoint's maxpacketsize, resulting in more transactions for the device to handle.