SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2

[andva]

Cool find! However, I'm _much_ more intrigued by fact #2....

To recap. Connecting in MSC mode, you find a file in the root directory (MTABLE.SYS) which contains the song database. In that file, you can see the following:

- the "drive letters" are "mmc:0" for the internal memory and (I think) "mmc:1" for the microSD card
- the format is (roughly) path, filename, album, artist, songname, genre and something else. The stock music is readily "seen" by the driver as being within the ##MUSIC# subdirectory. For instance:

mmc:0:\##MUSIC#\Music\Alias & Ehren\Lillian\

whereas the music copied over by using MSC are within (say) mmc:0:\MUSIC\whatever.

Besides, if you run "strings" on a firmware file, you'll see many references to ##MUSIC# and ##PORT#.

Since bclick found that these subdirectories were readily accessible, I suspected that they should be on the FAT somewhere, since that's the only place where the directory name is stored. (If it was, say, hardcoded to some sector, the directory contents could be found, but not the name). I tried making a directory called ##MUSIC# and seeing whether I could access the music. No dice. The directory was empty, and when I disconnected and reconnected, it had disappeared.

I then inspected the FAT in the device, and I have found the trick that the Sansa uses to hide the directories. They are regular files, but they have an attribute byte of 0x18. These two bits mean "directory" (0x10) and "volume label" (0x08). Since volume labels are ignored, no regular FAT driver is able to see the directory. But they are regular directories; you can go to the corresponding cluster and see the directory contents just fine.

I'm now using lde (Linux Disk Editor) to peruse the contents of the drive and I'm making some advances, although the ##MUSIC# directory is giving me problems (maybe there's another layer of protection so that the stock music can't be copied). But I can go to the PORT directory just fine. I'll keep you posted on that one.

EDIT - It is rather trivial to access the directories - just use an hex editor and change the 0x18 byte to 0x10, then remount the partition. I have successfully made a copy of ##MUSIC# and ##PORT# that way. (I rechanged the attributes byte to 0x18 before unplugging, so I don't know whether the Sansa would have reverted the change or not).

##PORT# does not look very promising, though (##MUSIC#, as  could be expected, contains the stock music). It contains a few images, the icon for the device, and "Object.dat" (mine is like 80Mb long, though). But I'd say "object.dat" is some kind of image of the device status (it seems to contain all the stock music, plus one recording I made as a test). I found no firmware references in the file.

I have also found that the ##MUSIC# directory I manually created was stored in the FAT, and that the Sansa had indeed changed its attributes to 0x18 (so there were actually two ##MUSIC# directories). Interestingly, the directory did contain an empty "skeleton" with the same subdirectories (and even files) making up the structure of the regular ##MUSIC# directory. Part of me wants to try what would happen when creating a ##PORT# directory, but my intuition is that it might not be a great idea

[bclick]

Nice work, m8, thanks for picking up on that and making the effort...

Hopefully this pace of discoveries will continue!

[andva]

OK, so I'm now trying to get more firmware images by tinkering with the Sansa Updater. I have been using a packet sniffer (Wireshark) to get info about the update process. To be honest, I did not come up with that idea myself, I have seen it previously somewhere (I can't remember the exact place, maybe in the abi forums).

My findings so far:

The update procedure is initiated by the Sansa Updater program by requesting the following URL:

http://sansa.directory.flashcp.com/cocoon/bls/directory/get-project-details?dummy=dummy&project-id=SANSA

The Sansa Updater sets the User-Agent string to "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SansaUpdater)", but the server does not seem to mind. The above URL opens just fine under Firefox.

The result is a lengthy string which contains a few url-encoded parameters. Once unmangled, the information returned is:

status=ok
application-home-prefix=https://fe.gummo.flashcp.com/cocoon/bls/updates/SANSA/fe
project-server-prefix=https://fe.gummo.flashcp.com/cocoon/bls/updates/SANSA/fe
time-server-prefix=http://time.gummo.flashcp.com/cocoon/bls/time
project-server-keys=
time-server-keys=

There is another string (project) which seems to contain the same information, URL-encoded a second time.

It is not possible to access those URLs directly, they yield a Forbidden error. I'm now looking at the strings on "sansaupdater.exe" and trying to make some sense out of them; the updates info is probably obtained by adding several suffixes to the "project-server-prefix", including USB IDs and model numbers (and, maybe, some kind of device serial). If anybody wants to join the fun, be advised that the file is UPX-compressed.

@bclick: Thanks! You were the one starting it all  

[andva]

I then tried to find that 90MB message within the firmware, but didn't find it, yet.

Was the exact message "Not enough space for Music DB. Please free 90MB", maybe? It is on the firmware, and it is repeated in quite a few places (it seems to be the same in all locales).

The message, along with a bunch others, are UTF-16 encoded, little-endian. You can get a list of all those messages with "strings -e l e200pa.bin", or an adequate variation (Linux guy here).

I would say that everything that is meant to be shown on the player screen is UTF16 encoded.

I'm going over the non-UTF16 encoded strings. Some of them are rather interesting (for instance, something is supposed to trigger when you place a file called "ERASEME.CMD" in the flash root... and I bet that the earphones testing plays a file called "diagnosis.mp3" also located there). They are trivial to get by using "strings", but I can post the results somewhere if you want.

By the way. I was wrong when assuming that the recovery mode could be triggered by doing something before the "System shutdown" message which appears when you try to power up the device with HOLD engaged. These messages can be found on the firmware (non-UTF16 encoded) and, therefore, if they can be seen on the screen, it's already too late.

I suppose a lot of people have tried button combinations, but, just to confirm, did anybody try them while spinning the wheel? Each "click" counts like a button press.

Something very intriguing: There is a non-UTF16 encoded string which reads "Erase Firmware? Press center button to confirm". On the firmware file. If we can somehow get to the point where the firmware can be erased from within itself, I would suppose that the player would boot on the recovery mode. (Or be borked for all eternity

PS: I would also be in favor of contributing towards buying one or more Rockbox "senior" developers an v2 player, but I fully understand that they may not have the time, energy or inclination to assume the huge burden of porting Rockbox to the v2's.

[DemonicAHole]

I suppose a lot of people have tried button combinations, but, just to confirm, did anybody try them while spinning the wheel? Each "click" counts like a button press.

i tried to do that but to no luck, just does the usual "hold is on..system shutdown"

-p.s. i did it with hold on and then off, wheel goin both directions

[andva]

Next installment: some work on the firmware format. Disclaimer: I don't know a thing about ARM code, but I can try to help

I have inspected the firmware binary file (for the e200), and, specifically, the "deadbeef" packing appearances. I have found some interesting structure to it, and I'll post it here in hopes that somebody with more knowledge of ARM assembler can pick it up.

The firmware seems to be divided in some kind of logical "blocks". The first area of the firmware comprises the first 122368 bytes (from 0 to just before 0x1DE00). Then, for simplification, the rest of the firmware can be divided on 77 blocks, each exactly 200 kb (204800 bytes) in size save for the last, which is ~40 kb. For convenience I have numbered these blocks 00 to 76 (I used a splitting utility). So the "header block" begins at the beginning of the firmware and is 122368 bytes long, and then "block N" begins at 122368+204800 * N (in hex, 1DE00 + 32000 * N) and is 200 kb long.

All the first blocks (the header and blocks 00 through 15) use padding. The padding is invariably a bunch of 0xFF bytes until what seems to be the next multiple of 512 (0x200), followed by 0xDEADBEEF padding until the end of the block. (This is not apparent in the header block because there is only a short FF section and no DEADBEEF; in fact, what I did was looking for the end of the DEADBEEF sequences, finding that they always were located 204800 bytes apart, and then extrapolating back to find the end of the header block.) These blocks look like some kind of "libraries" of code. I suspect that the main bulk of the code lies there.

By inspecting the strings, one can guess what each block is for:

Beginning block: initialization, basic filesystem operations, "tasks" (there are a few defined: Control Task, Decoder, Encoder, etc), a suspicious string which says "ASW is erased!", date and time functions, and probably the component which updates the firmware (the string E200P*.BIN is a giveaway)

Block 0: seems to be something related to the DRM
Block 1: more DRM-related things, a bunch of magic numbers, and what seems to be the default boot sector (maybe the formatting routine)
Block 2: something having to do with MSC (string: "Mass storage only"), libjpeg, and more magic numbers (video decoder?) Some firmware-related things, M3U reader, MTABLE.SYS reader, recorder, and Rhapsody-related things.
Block 3: Audible decoding, test mode, MTP implementation
block 4: no idea, could be some kind of image

From now on, one can find some of the functions referenced in the beginning block. The giveaway is that, at the end of each block, there is a string with the function name, plus "cr_5_0_develop" and what looks like a timestamp.

block 5: video decoder (near the end of the block, the string is "mp4_decoder")
block 6: mp3_decoder
block 7: wav_codec (recorder/player)
block 8: aud_decoder (Audible)
block 9: drmpd_persi (DRM related, probably)
block 10: Microsoft DRM in all its glory (drmpd_unlro and a few more things, the strings are a giveaway with things like "ExpirationDate", "FirstUseDate", etc).
block 11: drm_unloc function
block 12: wma decoder
block 13: more wma related functions
block 14: yet more wma/drm functions (it's disgusting how complex DRM is to implement!!)

Block 15 is totally empty (0x200 bytes of 0xFF padding, then DEADBEEF)

Blocks 16 to 22 seem to be data. Some of it looks like images. 17 and 18 contain all localization strings. 18 also contains the Rhapsody capabilities XML.

Block 23 contains the device certificate for the SANSA (more DRM things). There is some weird padding in it.

Block 24 is all DEADBEEF.

From now on, most blocks contain no recognizable strings. I think they contain all the artwork for the player, with no padding. Sometimes, the string HEADER pops up, but I don't know if it is supposed to mark the beginning of some data file.

From 71 on all blocks are all DEADBEEF, save for the very last 4 bytes, which, as Bagder has stated, could be some kind of checksum.

Hope this is of some use.

[hth]

I then tried to find that 90MB message within the firmware, but didn't find it, yet.

Was the exact message "Not enough space for Music DB. Please free 90MB", maybe? It is on the firmware, and it is repeated in quite a few laces (it seems to be the same in all locales).

Thank you! It was the message.

If we can somehow get to the point where the firmware can be erased from within itself, I would suppose that the player would boot on the recovery mode. (Or be borked for all eternity

Yes, there might be a chance, that after that the player would turn into
a mode supporting initial factory programming, but i'm not sure.

On the one hand, the rom on the SanDisk SoC may contain a different or elder bootloader not supporting usb proming.

On the other hand, i'm missing information on what the AMS rom-bootloader would do exactly and specifically, after triggering a usb bootloading mode. Maybe we trigger it, but don't see anything happening because it's

1. expecting to read the firmware from an usb device in a certain format (which is not described in the datasheet).
2. not able to control the lcd and thus able to display a message like 'no firmware for update found, bootstaging from nand.'

[edit]merge of follow up posting:

Next installment: some work on the firmware format. Disclaimer: I don't know a thing about ARM code, but I can try to help

Great work! I neither know much about ARM, but i've started reading quite a lot about it.

I hope the SoC supports fetching and executing instructions directly from the iNand after mapping the NAND memory into it's address space. As rockbox uses memory statically, it maybe able to reserve about 50k internal RAM for variables, another ~150k buffer for audio decoding and the remaining 120k free for other things.

If so, i will buy a cheaper DAP without additional SDRAM like the Sansa Clip and start coding a bootloader on that, first (in about two weeks, for i don't have much time until then). If it bricks, who cares, but i don't wanna brick my e280...

[edit]forgot something i tested out at home:
1. On e200 v2 players, the firmware copied into root must be renamed to e200pt.bin to enable diagnostic mode (so diagnostic menu may work on the m200 v2s as well).
2. Firmware updates (triggered by any file named e200p*.bin within root directory):

• Initiate firmware update, display "Updating firmware."
• Read the e200p*.bin, is it a valid firmware image? (1)
• (1) Yes:
  Flash to NAND, display "Upgrade completed" message, then turn off
• (1) No:
  Do nothing, just turn off, display nothing further

[andva]

I wouldn't be _that_ surprised if the wheel had something to do with entering recovery mode. It is a remote possibility, since that would probably make it somewhat unreliable (you'd have to "click" just at the right time), but it can't be ruled out. The fact that the Clip does not have any rotary encoder is not definitive - after all, the e2x0v2 does have the same key that the c200 uses for (what seems to be) recovery mode, but the same trick does not work.

However, if the c200 has it, then I'm convinced that the e200 (more expensive, more complex) will also have a way of getting it into recovery mode. If the c200 way of doing it is any indication, then the steps are simple: turn off, set HOLD, hold a button (<< on the c200, but it does not work on the e200), plug it in, see what happens. We'll have to try one more time.

With regards to the firmware files, if the "blocks" theory is correct, there are some interesting implications. The firmware-related strings (a la "Updating firmware") are, along with (almost) all others shown on the screen, on block 17. (Rule of thumb: If it is shown on the screen, it's UTF-16 encoded and on blocks 17 or 18). However, the glob pattern (E200P*.BIN, for my non-Rhapsody e200v2 player) is on the "beginning block" (along with the misterious ASW reference... ¿does the SoC have something called an "ASW"?). To complicate matters further, in block 2 there are some more intriguing references.

This is part of the result of running strings on block 2:

Code: [Select]

e200pV03
E200P.BIN
mmc:0:\ERASEME.CMD
Do Not Release This File In Public. Copyright SanDisk Corp. 2007
mmc:\UPGRADE.FIN
e200pSelfErase
#EXTM3U
#EXTINF:
Unknown
mmc:\MTABLE.SYS
##MUSIC#
FM%d_%01d-%02d%02d%02d-%02d%02d%02d
VORC0000.WAV
FMRC0000.WAV
thumbnail
%02d%02d%02d-%02d%02d%02d

ERASEME.CMD, E200P.BIN, UPGRADE.FIN and e200pSelfErase, to name a few, seem enticing.

Then, right after the e200pSelfErase reference (offset 0x2fabc), there is what, methinks, is the table with the allowed values for the firmware suffixes:

Code: [Select]

0002fabc  54 01 01 01 01 00 01 01  41 01 00 00 01 00 01 00  |T.......A.......|
0002facc  45 00 00 00 01 00 00 00  50 01 00 00 01 00 01 00  |E.......P.......|
0002fadc  46 01 00 00 01 00 00 00  47 00 01 00 01 15 00 00  |F.......G.......|
0002faec  48 01 01 00 01 15 00 00  4d 00 00 01 01 17 00 00  |H.......M.......|
0002fafc  4e 01 00 01 01 17 00 00  53 00 00 00 01 00 01 00  |N.......S.......|

Something interesting can be seen if we divide each row in two:

Code: [Select]

T: 54 01 01 01 01 00 01 01
A: 41 01 00 00 01 00 01 00
E: 45 00 00 00 01 00 00 00  
P: 50 01 00 00 01 00 01 00
F: 46 01 00 00 01 00 00 00
G: 47 00 01 00 01 15 00 00
H: 48 01 01 00 01 15 00 00
M: 4d 00 00 01 01 17 00 00
N: 4e 01 00 01 01 17 00 00
S: 53 00 00 00 01 00 01 00

Of the 8-byte counts, the first one is the prefix, and the other seven seem to be flags. We'll number them flag 1 through flag 7. Flags can (seemingly) take either 00 or 01 as a value, save for flag 5, which can be 00, 15 (21 decimal) or 17 (23 decimal). It seems that the firmware decides (in part) what set of capabilities it will have just looking at its suffix!

I have also reviewed bclick's original post at abi, where he took the time to go through all the letters with his m300 (thanks! . The only letters which did anything where the 10 letters in the table above.

Flag 1: By looking at the way it varies, I'd bet that this flag means whether the radio is enabled or not. This seems consistent with bclick's findings.

Flag 2 is only 1 for H, G and the test firmware. bclick reported that, in the m300, H and G were Hebrew and Greek respectively. So maybe this is an "allow alternate font" flag or something of the sort. Or, maybe, an option which controls whether Greek/Hebrew are present as options in the language selection dialog.

Flag 3 is only 1 for M, N and the test firmware. Same as above with "Arabic" (as bclick reported).

Flag 4 is always 1, so there's no way of knowing what it means.

Flag 5 is probably the default font/character encoding. I recall bclick reporting that, in the m300, M and N looked "like Arabic" (flag = 17), G Greek, and H Hebrew (both flag = 15). All others use the default font. The fact that this is the only flag that the test mode does not set is also worth noting.

Flag 6: I don't really know. Maybe whether the "high" volume option will appear on the menu?

Flag 7 is (quite probably) whether the "test" option will appear on the menu or not. It is only 01 for T, the test firmware.

From what I have gathered, I don't expect any other letter (or combination) to be accepted as a firmware update. Creating an ERASEME.CMD file on the root directory will probably reformat the Sansa (similar to the .fmt method for v1 hardware), but I'm not trying it just yet...

OK, (high) time to go to bed here in Europe. I expect something cool to have happened on the forum as I sleep, don't let me down!

Cheers to all!

[bclick]

andva - Great work and excellent deductive reasoning. I had just duplicated that very effort, and came here to share it - it's still great to be late to the party!

On flag byte #5 - the T version has ALL languages supported. It is also confirmed that the Hebrew version omits Arabic, and vice versa (for socio-political reasons I suppose). All the other languages are supported by these versions. BTW, G&H are both Hebrew and M&N both Arabic; the difference of course being the radio enable bit.

I came upon the *.BIN suffix letters searching in the m300 FW (at 1D5F4) and at once realized I could have avoided trying all the letters...LOL...and the byte mask jumped out next. In the m300 (Clip, for me) FW, it is identical to what you have listed. So that's great - parallelism between models...

If you search for reference to the "version.sdk" file, it appears that this is written out if missing, using hardcoded strings from within the FW (but the FW version is dynamically written out..between the hard coded strings). Bear with me...

Now, what I suspect the ERASEME.CMD file contains is the text "Do Not Release.." etc., and some factory test / action results in the device writing this file to mmc:0:\ (root), possibly as a flash file system test file / debug flag.

Note the m300 FW appears to have nearly all the rest, including refs to JPG files (which, just ain't no way...), and a diagnostic menu for SD slot testing, as it's bigger brothers. Plenty of commonality. But on the Clip, the "free up space" string calls for "only" 30MB...

saratoga - good points. Somebody has to always throw cold water on!

j/k  - but even if a full RB port to the Clip is not feasible, there are those who would still be interested in exploring the possibilities and doing a little bit of "personalization", optimization, or plain old awakening of resident but inactive features. MP3 encoding for radio and voice recording alone would be huge.

EDIT - I put an ERASEME.CMD file on there (with just that notice text, no CR/LF), restarted, and....nothing. Music was not deleted, so it's presence alone won't trigger a format. The .CMD file itself was deleted, however.

AND - the UPGRADE.FIN file is written out after a firmware upgrade. I found it by loading a "new" FW file, disconnecting (FW loads, then shuts down), then connecting in "forced MSC mode" (unit OFF, switch in HOLD position, press center button, plug in cable, wait till "connected" is displayed, release center button). Apparently some house cleaning is pending. It contains a single byte (0x03) that decrements with each such connection, and it is deleted when it reaches 0 or the device is connected normally (I think). Anyway it's nothing very exciting.

I have also found that the FW can be loaded without any "region code" at all; as "m300.bin" it simply updates the existing version. Probably what the Sansa Updater delivers...

AND, m300SelfErase is nothing more than yet another mechanism to load firmware. I first tried placing a 0 byte file w/ that name, the Firmware Updating message came up, but no Completion. Renamed a copy of the FW file, and in it went, to completion - without altering the region code already in place.

EDIT Ditto for "m300V01"; yet ANOTHER FW filename... Sheesh! Wish there was something more useful to report - but at least, this is another "known"...

And no, ERASEME.CMD is not another way to load FW, and yes, I tried it  

[hth]

While measuring here and there on an e200 v2, i found out something that maybe interesting:
On the right side of the front pcb (under the lcd, on its back is the micro-sd slot, about half an inch above the headphone), there are 8 blank connectors.
At the top of them, there's an arrow and the text DIP. I start counting the most top connector with 1, thus the bottom one is 8. The connectors are no dupe of the micro sd signals - which was what made me curious:

Measurings are quite inaccurate (about 2% tolerance)
Li-Io Battery: GND1..BVDD: 3.95V; GND2..BVDD: 3.91-3.92V
Resistance[Ohm] to GND: 1:15-17.5k; 2..7: INF; 8: 0
Voltage[V] to GND:

Code: [Select]

  Descr.;Supply over USB only; Battery supply only
1: VDD?? ; 3.12-3.13; 3.14
2: NC??? ; 0.00; 0.00
3: ??    ; 2.45; 2.46
4: ??    ; 2.45; 2.47
5: ??    ; 2.45; 2.46
6: ??    ; 2.45; 2.46
7: RST?? ; 2.90; 2.90
8: GND   ;
7: Looks like the player is off for less than a sec, then while still
   measuring:
   1.) SanDisk Sansa logo displays (like when turning on)
   2.) a) USB Connected: Connected message displays
   2.) b) No USB: Last screen displayed again, then music database is
                  reread
   This looks like a kind of reset, the 2.90V did not change.
   So maybe this connector is for diagnosis purposes!!!

[Igge]

Hello!

I'm very interested in a Rockbox version for the e200v2, too.

How big is the chance that there's a key combination for a recovery mode? I tried many combinations but none worked. And why should Sandisk change the key combination? Or is it a fact that a recovery mode is triggered by software?

FYI I made some pictures of my open e250v2. Feel free to use it:

http://img136.imageshack.us/my.php?image=img9629ny4.jpg
http://img136.imageshack.us/my.php?image=img9633ru5.jpg
http://img136.imageshack.us/my.php?image=img9640rw1.jpg

Igge

[Kakuwinki]

Like I mentioned in this thread http://forums.rockbox.org/index.php?topic=13961.15, I have found a way to make the sansa e200v2 to stay on the opening video for about 30 seconds. Maybe at that moment, something should be tried to go in recovery mode?

[dan_a]

I've made a (very small) start on the Rockbox code for the V2s.  At the moment there's huge amounts missing - but hopefully I'll fill those in as I go.  For those using git it's in the Sansa_v2 branch at git://www.md1clv.com/Rockbox.git

[rasher]

If you have one of these devices (except for the e280v2), please read this post which I accidentally posted over in the strict e200v2 thread, but meant to post here: http://forums.rockbox.org/index.php?topic=13961.msg117138#msg117138 and help us out with the USB vid/pids for your device.

[ilikerockbox]

Sansa Clip:

MTP
Bus 001 Device 118: ID 0781:7432 SanDisk Corp.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x0781 SanDisk Corp.
  idProduct          0x7432
  bcdDevice           d3.38
  iManufacturer           1 SanDisk
  iProduct                2 SanDisk Sansa Clip
  iSerial                 3 5011F4065888B49F0000000000000000
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           39
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          4 config1: Mass Storage only
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass         0 (Defined at Interface level)
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              5 sic ifac 1 (Capture::PIMA)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               4
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0000
  (Bus Powered)