TUSB9261: Failure to send data

Hello Ryan,

Sorry to jump in, but from what I can see in the logs, the -i option doesn’t appear to be set correctly (the -s option looks fine).
It seems that the hyphen used for -i is different from the one used for -s.
Could you please make sure they match and try again?

Best Regards,
Yuya

Hi Yuya,

Good eye, I do believe you were right. I made that change and I'm at least getting some different results, though still not the right ones: 

admin@raspberrypi:~ $ sg_raw -r 1k /media/admin/a107acc3-2c69-4ef3-a420-74b52c35955b 12 00 00 00 60 00
/media/admin/a107acc3-2c69-4ef3-a420-74b52c35955b: Is a directory
admin@raspberrypi:~ $ sg_raw -r 1k /media/admin 12 00 00 00 60 00
/media/admin: Is a directory
admin@raspberrypi:~ $ sg_raw -r 512 -i /media/admin a1 28 2d 52 00 00 00 00 00 81 00 00
a1: No such file or directory
admin@raspberrypi:~ $ sg_raw -r 512 -i /media/admin 800 GB Volume a1 28 2d 52 00 00 00 00 00 81 00 00
Invalid command byte 'GB'
Usage: sg_raw [OPTION]* DEVICE [CDB0 CDB1 ...]

Options:
  --binary|-b            Dump data in binary form, even when writing to
                         stdout
  --cmdfile=CF|-c CF     CF is file containing command in hex bytes
  --cmdset=CS|-C CS      CS is 0 (def) heuristic chooses command set;
                         1: force SCSI; 2: force NVMe
  --enumerate|-e         Decodes cdb name then exits; requires DEVICE but
                         ignores it
  --help|-h              Show this message and exit
  --infile=IFILE|-i IFILE    Read data to send from IFILE (default:
                             stdin)
  --nosense|-n           Don't display sense information
  --nvm|-N               command is for NVM command set (e.g. Read);
                         default, if NVMe fd, Admin command set
  --outfile=OFILE|-o OFILE    Write binary data to OFILE (def: hexdump
                              to stdout)
  --raw|-w               interpret CF (command file) as binary (def:
                         interpret as ASCII hex)
  --readonly|-R          Open DEVICE read-only (default: read-write)
  --request=RLEN|-r RLEN    Request up to RLEN bytes of data (data-in)
  --scan=FO,LO|-Q FO,LO    scan command set from FO (first opcode)
                           to LO (last opcode) inclusive. Uses given
                           command bytes, varying the opcode
  --send=SLEN|-s SLEN    Send SLEN bytes of data (data-out)
  --skip=KLEN|-k KLEN    Skip the first KLEN bytes when reading
                         data to send (default: 0)
  --timeout=SECS|-t SECS    Timeout in seconds (default: 20)
  --verbose|-v           Increase verbosity
  --version|-V           Show version information and exit

Between 6 and 260 command bytes (two hex digits each) can be specified
and will be sent to DEVICE. Lengths RLEN, SLEN and KLEN are decimal by
default. Bidirectional commands accepted.

Simple example: Perform INQUIRY on /dev/sg0:
  sg_raw -r 1k /dev/sg0 12 00 00 00 60 00
admin@raspberrypi:~ $ sg_raw -r 512 -i /media/admin 800 GB Volume a1 28 2d 52 00 00 00 00 00 81 00 00
Invalid command byte 'GB'
Usage: sg_raw [OPTION]* DEVICE [CDB0 CDB1 ...]

Options:
  --binary|-b            Dump data in binary form, even when writing to
                         stdout
  --cmdfile=CF|-c CF     CF is file containing command in hex bytes
  --cmdset=CS|-C CS      CS is 0 (def) heuristic chooses command set;
                         1: force SCSI; 2: force NVMe
  --enumerate|-e         Decodes cdb name then exits; requires DEVICE but
                         ignores it
  --help|-h              Show this message and exit
  --infile=IFILE|-i IFILE    Read data to send from IFILE (default:
                             stdin)
  --nosense|-n           Don't display sense information
  --nvm|-N               command is for NVM command set (e.g. Read);
                         default, if NVMe fd, Admin command set
  --outfile=OFILE|-o OFILE    Write binary data to OFILE (def: hexdump
                              to stdout)
  --raw|-w               interpret CF (command file) as binary (def:
                         interpret as ASCII hex)
  --readonly|-R          Open DEVICE read-only (default: read-write)
  --request=RLEN|-r RLEN    Request up to RLEN bytes of data (data-in)
  --scan=FO,LO|-Q FO,LO    scan command set from FO (first opcode)
                           to LO (last opcode) inclusive. Uses given
                           command bytes, varying the opcode
  --send=SLEN|-s SLEN    Send SLEN bytes of data (data-out)
  --skip=KLEN|-k KLEN    Skip the first KLEN bytes when reading
                         data to send (default: 0)
  --timeout=SECS|-t SECS    Timeout in seconds (default: 20)
  --verbose|-v           Increase verbosity
  --version|-V           Show version information and exit

Between 6 and 260 command bytes (two hex digits each) can be specified
and will be sent to DEVICE. Lengths RLEN, SLEN and KLEN are decimal by
default. Bidirectional commands accepted.

Simple example: Perform INQUIRY on /dev/sg0:
  sg_raw -r 1k /dev/sg0 12 00 00 00 60 00
admin@raspberrypi:~ $ sg_raw -r 512 -i /media/admin/a107acc3-2c69-4ef3-a420-74b52c35955b a1 28 2d 52 00 00 00 00 00 81 00 00
a1: No such file or directory
admin@raspberrypi:~ $ sg_raw -r 512 -i /media/admin/a107acc3-2c69-4ef3-a420-74b52c35955b    a1 28 2d 52 00 00 00 00 00 81 00 00
a1: No such file or directory
admin@raspberrypi:~ $ sg_raw -r 512 -i /media/admin/a107acc3-2c69-4ef3-a420-74b52c35955ba1 28 2d 52 00 00 00 00 00 81 00 00
28: No such file or directory
admin@raspberrypi:~ $ sg_raw -r 512 -i /media/admin a1 28 2d 52 00 00 00 00 00 81 00 00
a1: No such file or directory
admin@raspberrypi:~ $ 

One thing I did notice outside of trying to send these commands, I noticed that I can't send files to and from the SSD, it's giving me a Permission Denied error. Would it be a good idea to reformat the drive as EXT4 to see if that would fix it? If you, I can go ahead and try that.

Thanks,

Ryan

Hi Ryan,

It seems that the correct command has not been sent based on the log. Could you please use the following command?

sg_raw -r 512 "Destination Directory (SSD directory)" a1 2a 25 52 00 00 00 00 00 81 00 00

Also, could you please try the following command when sending the file?

sg_raw -r 512 -i auth_device.bin "Destination Directory (SSD directory)" a1 2a 25 51 00 00 00 00 00 81 00 00

As a precautionary check, the destination directory can also be specified with an absolute path, so could you please try that option as well?

Best Regards,

Yuya

Hi Yuya,

I tried those commands as well, and I saw still seeing the "is a directory" return. It seems like it's either just pinging to see if it exists, or is returning an error like you said:

admin@raspberrypi:~/Desktop/test environment $ sg_raw -r 512 /media/admin/a107acc3-2c69-4ef3-a420-74b52c35955b a1 2a 25 52 00 00 00 00 00 81 00 00
/media/admin/a107acc3-2c69-4ef3-a420-74b52c35955b: Is a directory
admin@raspberrypi:~/Desktop/test environment $ sg_raw -r 512 -i auth_device.bin /media/admin/a107acc3-2c69-4ef3-a420-74b52c35955b a1 2a 25 52 00 00 00 00 00 81 00 00
/media/admin/a107acc3-2c69-4ef3-a420-74b52c35955b: Is a directory
admin@raspberrypi:~/Desktop/test environment $ sg_raw -r 512 /media/admin/a107acc3-2c69-4ef3-a420-74b52c35955b a1 2a 25 52 00 00 00 00 00 81 00 00
/media/admin/a107acc3-2c69-4ef3-a420-74b52c35955b: Is a directory
admin@raspberrypi:~/Desktop/test environment $ sg_raw -r 512 -i /home/admin/Desktop/test environment/auth_device.bin /media/admin/a107acc3-2c69-4ef3-a420-74b52c35955b a1 2a 25 52 00 00 00 00 00 81 00 00
Invalid command byte '/media/admin/a107acc3-2c69-4ef3-a420-74b52c35955b'
Usage: sg_raw [OPTION]* DEVICE [CDB0 CDB1 ...]

Options:
  --binary|-b            Dump data in binary form, even when writing to
                         stdout
  --cmdfile=CF|-c CF     CF is file containing command in hex bytes
  --cmdset=CS|-C CS      CS is 0 (def) heuristic chooses command set;
                         1: force SCSI; 2: force NVMe
  --enumerate|-e         Decodes cdb name then exits; requires DEVICE but
                         ignores it
  --help|-h              Show this message and exit
  --infile=IFILE|-i IFILE    Read data to send from IFILE (default:
                             stdin)
  --nosense|-n           Don't display sense information
  --nvm|-N               command is for NVM command set (e.g. Read);
                         default, if NVMe fd, Admin command set
  --outfile=OFILE|-o OFILE    Write binary data to OFILE (def: hexdump
                              to stdout)
  --raw|-w               interpret CF (command file) as binary (def:
                         interpret as ASCII hex)
  --readonly|-R          Open DEVICE read-only (default: read-write)
  --request=RLEN|-r RLEN    Request up to RLEN bytes of data (data-in)
  --scan=FO,LO|-Q FO,LO    scan command set from FO (first opcode)
                           to LO (last opcode) inclusive. Uses given
                           command bytes, varying the opcode
  --send=SLEN|-s SLEN    Send SLEN bytes of data (data-out)
  --skip=KLEN|-k KLEN    Skip the first KLEN bytes when reading
                         data to send (default: 0)
  --timeout=SECS|-t SECS    Timeout in seconds (default: 20)
  --verbose|-v           Increase verbosity
  --version|-V           Show version information and exit

Between 6 and 260 command bytes (two hex digits each) can be specified
and will be sent to DEVICE. Lengths RLEN, SLEN and KLEN are decimal by
default. Bidirectional commands accepted.

Simple example: Perform INQUIRY on /dev/sg0:
  sg_raw -r 1k /dev/sg0 12 00 00 00 60 00
admin@raspberrypi:~/Desktop/test environment $ sg_raw -r 512 -i auth_device.bin "/media/admin/a107acc3-2c69-4ef3-a420-74b52c35955b" a1 2a 25 52 00 00 00 00 00 81 00 00
/media/admin/a107acc3-2c69-4ef3-a420-74b52c35955b: Is a directory

What do you think could be causing these errors? Something SCSI related, or maybe permissions?

Thanks,

Ryan

Hi Ryan,

It seems that you are getting an error because the device file is not specified correctly. What you are currently specifying is probably the directory where the device is mounted. I believe you should specify the original device file.

Please try using the 'lsblk' command to find it

lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    0   120G  0 disk 
|-sda1        8:1    0 119.1G  0 part /media/XXXX

If the device is mounted like this, please specify the 'sda' directory and send the command.
For example, when you send the IDENTIFY DEVICE command, success would look like this.

[2025-06-20 12:48:36.528] 
[2025-06-20 12:48:36.530] root@imx8mn-ddr4-evk:~# sg_raw -r 512 /dev/sda a1 28 2d 00 00 00 00 00 00 ec 00 00
[2025-06-20 12:48:38.700] SCSI Status: Check Condition 
[2025-06-20 12:48:38.700] 
[2025-06-20 12:48:38.700] Sense Information:
[2025-06-20 12:48:38.709] Fixed format, current; Sense key: Recovered Error
[2025-06-20 12:48:38.709] Additional sense: ATA pass through information available
[2025-06-20 12:48:38.731]   error=0x0, status=0x0, device=0x0, count(7:0)=0x0 
[2025-06-20 12:48:38.731]   extend=0, log_index=0x0, lba_high,mid,low(7:0)=0x0,0x0,0x0 
[2025-06-20 12:48:38.731] 
[2025-06-20 12:48:38.731] Received 512 bytes of data:
[2025-06-20 12:48:38.731]  00     40 00 ff 3f 37 c8 10 00  00 00 00 00 3f 00 00 00    @..?7.......?...
[2025-06-20 12:48:38.731]  10     00 00 00 00 53 47 30 31  30 30 30 30 54 30 30 30    ....SG010000T000
[2025-06-20 12:48:38.758]  20     30 30 30 30 33 37 38 38  00 00 00 00 00 00 73 67    00003788......sg
[2025-06-20 12:48:38.758]  30     2e 31 31 62 30 30 42 47  72 44 76 69 72 65 47 20    .11b00BGrDvireG 
[2025-06-20 12:48:38.758]  40     31 53 20 20 20 20 20 20  20 20 20 20 20 20 20 20    1S              
[2025-06-20 12:48:38.778]  50     20 20 20 20 20 20 20 20  20 20 20 20 20 20 01 80                  ..
[2025-06-20 12:48:38.778]  60     00 40 00 0f 01 40 00 00  00 00 07 00 ff 3f 10 00    .@...@.......?..
[2025-06-20 12:48:38.778]  70     3f 00 10 fc fb 00 01 01  00 00 00 0f 00 00 07 00    ?...............
[2025-06-20 12:48:38.802]  80     03 00 78 00 78 00 78 00  78 00 00 02 00 00 00 00    ..x.x.x.x.......
[2025-06-20 12:48:38.802]  90     00 00 00 00 00 00 1f 00  0e 05 04 00 48 00 40 00    ............H.@.
[2025-06-20 12:48:38.802]  a0     fe 07 6d 00 6b 74 01 75  62 40 69 74 01 b4 62 40    ..m.kt.ub@it..b@
[2025-06-20 12:48:38.809]  b0     7f 40 00 00 00 00 00 00  fe ff 00 00 00 00 00 00    .@..............
[2025-06-20 12:48:38.811]  c0     00 00 00 00 00 00 00 00  00 00 00 0f 00 00 00 00    ................
[2025-06-20 12:48:38.817]  d0     00 00 01 00 00 40 00 00  00 00 00 00 00 00 00 00    .....@..........
[2025-06-20 12:48:38.835]  e0     00 00 00 00 00 00 00 00  00 00 00 00 00 00 14 40    ...............@
[2025-06-20 12:48:38.835]  f0     14 40 00 00 00 00 00 00  00 00 00 00 00 00 00 00    .@..............
[2025-06-20 12:48:38.835]  100    21 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    !...............
[2025-06-20 12:48:38.843]  110    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
[2025-06-20 12:48:38.850]  120    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
[2025-06-20 12:48:38.857]  130    11 10 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
[2025-06-20 12:48:38.863]  140    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
[2025-06-20 12:48:38.869]  150    00 00 01 00 20 20 20 20  20 20 20 20 00 00 00 00    ....        ....
[2025-06-20 12:48:38.875]  160    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
[2025-06-20 12:48:38.884]  170    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
[2025-06-20 12:48:38.890]  180    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
[2025-06-20 12:48:38.897]  190    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
[2025-06-20 12:48:38.905]  1a0    00 00 00 40 00 00 00 00  00 00 00 00 00 00 00 00    ...@............
[2025-06-20 12:48:38.911]  1b0    00 00 00 00 00 00 00 00  00 00 00 00 7f 10 51 00    ..............Q.
[2025-06-20 12:48:38.918]  1c0    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
[2025-06-20 12:48:38.927]  1d0    00 00 00 00 01 00 09 02  00 00 00 00 00 00 00 00    ................
[2025-06-20 12:48:38.933]  1e0    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
[2025-06-20 12:48:38.942]  1f0    00 00 00 00 00 00 00 00  00 00 00 00 00 00 a5 a3    ................
[2025-06-20 12:48:38.958] root@imx8mn-ddr4-evk:~# 

Best Regards,

Yuya

Hi Yuya:

   Ryan is out today and will be back on next Monday.

Best

Brian

Hi Yuya,

Sorry for the late reply, I was out Friday and Monday with a fever.

I looked for the /sda directory like you said, and found the drive listed as /dev/sda1 . I tried testing with that, which I believe seems more along the lines of what the commands expects. However, I receive the following error: "/dev/sda1: Permission denied". If I had to guess, this is means the owner/PC this was originally formatted on is the only PC that can send this command.

Any recommendations on what to test next?

Thanks,

Ryan

Hi Ryan,

I'm glad to hear that you're feeling better. Please continue to take good care of yourself.

Regarding the error message:
/dev/sda1: Permission denied
—this gave me a good indication of the issue. It appears that the command being used requires root privileges, but it was executed without them, which is likely why the system denied access.

As a solution, please try adding sudo at the beginning of the command you’ve been using.

For example:

sudo sg_raw -r 512 /dev/sda a1 28 2d 00 00 00 00 00 00 ec 00 00

Would you be able to give that a try and let me know if it works?

Best Regards,

Yuya

Hi Yuya,

Good call, looks like that fixed it. I was able to send commands successfully, here are the results I got for the three commands listed in the test environment: 

admin@raspberrypi:~/Desktop/test environment $ sudo sg_raw -r 512 /dev/sda1 a1 2a 25 51 00 00 00 00 00 81 00 00
>>> transport error: Host_status=0x07 [DID_ERROR]
Driver_status=0x00 [DRIVER_OK]

SCSI Status: Good 

Error 99 occurred, no data received
admin@raspberrypi:~/Desktop/test environment $ sudo sg_raw -r 512 -i auth_device.bin /dev/sda1 a1 28 2d 51 00 00 00 00 00 81 00 00
SCSI Status: Check Condition 

Sense Information:
Fixed format, current; Sense key: Recovered Error
Additional sense: ATA pass through information available
  error=0x0, status=0x50, device=0xa0, count(7:0)=0x0 
  extend=0, log_index=0x0, lba_high,mid,low(7:0)=0x0,0x0,0x0 

Received 512 bytes of data:
 00     00 00 00 00 00 00 00 00  37 e8 1c 64 37 e8 1c 64    ........7..d7..d
 10     37 e8 1c 64 00 00 00 00  00 00 00 00 00 00 00 00    7..d............
 20     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 30     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 40     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 50     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 60     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 70     00 00 00 00 00 00 00 00  00 00 00 00 1b a8 00 00    ................
 80     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 90     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 a0     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 b0     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 c0     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 d0     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 e0     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 f0     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 100    ed 41 00 00 00 10 00 00  98 07 5b 68 37 e8 1c 64    .A........[h7..d
 110    37 e8 1c 64 00 00 00 00  00 00 03 00 08 00 00 00    7..d............
 120    00 00 08 00 00 00 00 00  0a f3 01 00 04 00 00 00    ................
 130    00 00 00 00 00 00 00 00  01 00 00 00 7f 24 00 00    .............$..
 140    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 150    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 160    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 170    00 00 00 00 00 00 00 00  00 00 00 00 63 6f 00 00    ............co..
 180    20 00 2d 86 00 00 00 00  00 00 00 00 ec bf 53 e9     .-...........S.
 190    37 e8 1c 64 00 00 00 00  00 00 00 00 00 00 00 00    7..d............
 1a0    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 1b0    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 1c0    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 1d0    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 1e0    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 1f0    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
admin@raspberrypi:~/Desktop/test environment $ sudo sg_raw -s 512 -i set_auth.bin /dev/sdX a1 0a 25 00 00 00 00 00 00 81 00 00
/dev/sdX: No such file or directory
admin@raspberrypi:~/Desktop/test environment $ sudo sg_raw -s 512 -i set_auth.bin /dev/sd1 a1 0a 25 00 00 00 00 00 00 81 00 00
/dev/sd1: No such file or directory
admin@raspberrypi:~/Desktop/test environment $ sudo sg_raw -s 512 -i set_auth.bin /dev/sda1 a1 0a 25 00 00 00 00 00 00 81 00 00
>>> transport error: Host_status=0x03 [DID_TIME_OUT]
Driver_status=0x00 [DRIVER_OK]

SCSI Status: Good 

admin@raspberrypi:~/Desktop/test environment $ sudo sg_raw -s 512 -i auth_device.bin /dev/sda1 a1 28 2d 51 00 00 00 00 00 81 00 00
>>> transport error: Host_status=0x07 [DID_ERROR]
Driver_status=0x00 [DRIVER_OK]

SCSI Status: Good 

From what I can tell compared to the test file environment, we see the same issue on our side of the "failure command" timing out and returning an error. At the same time, one of the successful commands, "sudo sg_raw -r 512 -i auth_device.bin /dev/sda1 a1 28 2d 51 00 00 00 00 00 81 00 00", returns the correct result I believe, while the other looks like it might have an incorrect response.

Give it a look and let me know what you think, I believe next steps on my side will be to get a protocol analyzer and figure out why that other command is timing out.

Thanks,

Ryan

Hi Ryan,

I ended up in exactly the same situation. I'm glad the problem has been resolved.
I agree with the next step as well. It would be great if you could use a protocol analyzer to figure out the cause.

Best Regards,

Yuya

Hi Yuya,

I'm working on getting the setup I need for this, I.E the analyzer itself and the software onto a computer I can use, I will let you know once I have it setup and what I see.

Thanks,

Ryan

Hi Ryan,

It has been a few days, how are things progressing on your end?

Best Regards,

Yuya

Hi Yuya,

Sorry for the wait on this. I've been having some trouble getting the software needed on my side with the protocol analyzer to record the protocol while these commands are sent. Once I have the software downloaded, I should be able to get a recording to share with you.

Thanks,

Ryan

Hi Ryan,

Understood. I will be waiting for your update.

Best Regards,

Yuya

Hi Ryan,

Could you please share the status?

Best Regards,

Yuya

Hi Yuya,

I'm so sorry for the wait. I have the software approved so I have that installed, however the analyzer we have is currently in demand for multiple projects. I should be able to get a chance tomorrow I believe to capture a trace, that way I can send it over to you for review and we can see if there is any indication where this time-out is happening.

Thanks,

Ryan

Hi Ryan,

Understood. I will be waiting for your report.

Best Regards,

Yuya

Hi Yuya,

I got a trace of sending the failed command from the linux pc to the SSD through the TUSB9261. Looking at the trace, however, it looks like the command is not being sent out at all. There's no signs of any USB3 SS activity, only the SSD disconnecting and reconnecting after the command times out it looks like:

Does this command work with other SSD's with no issues? Or is this any issue you see with any SATA to M.2 connection?

Thanks,

Ryan

Hi Ryan,

Sorry, I didn’t fully understand, so I have a question.
Is the command not being sent from the SSD, or is it from the TUSB9261?
I believe it roughly looks like the diagram below, but when looking at the USB analyzer, are you seeing information from① or ②?

>>Does this command work with other SSD's with no issues? 
I haven’t tested it with other SSDs because I only have the one SSD with the command enabled, which I sent to you.

>>Or is this any issue you see with any SATA to M.2 connection?
I’m not sure what this means. Could you please explain?

Best Regards,

Yuya

Hi Yuya,

Yuya Takashima said:

Sorry, I didn’t fully understand, so I have a question.
Is the command not being sent from the SSD, or is it from the TUSB9261?
I believe it roughly looks like the diagram below, but when looking at the USB analyzer, are you seeing information from① or ②?

It should be that when I type the command into the command prompt of the host PC, it's being sent by the Linux OS to the SSD through the TUSB9261. Is this command meant to cause the SSD to send a command to the PC? I thought the command was meant to be sent by the PC to either read data or configure the SSD.

We have the USB analyzer located between the Linux PC and the TUSB9261EVM. The signal is sent from the PC, routed through USB analyzer so it can read the signals as they pass through, and record the data to see what is being sent exactly, before going back out into the TUSB9261EVM. We don't have any analyzer capable of snooping between the TUSB9261 and the SSD.

Yuya Takashima said:

I’m not sure what this means. Could you please explain?

In order to test with this SSD, because it is an M.2 NVME SSD, we have a SATA to M.2 SSD enclosure we are using in order to connect the TUSB9261 to the SDD, as we do not have any way to connect our TUSB9261EVM directly to the SSD. 

Thanks,

Ryan

Hi Ryan,

Ryan Kitto said:

It should be that when I type the command into the command prompt of the host PC, it's being sent by the Linux OS to the SSD through the TUSB9261. Is this command meant to cause the SSD to send a command to the PC? I thought the command was meant to be sent by the PC to either read data or configure the SSD.

As you mentioned, the command is sent from the PC to read data from the SSD or to change the SSD's settings.

Ryan Kitto said:

We have the USB analyzer located between the Linux PC and the TUSB9261EVM. The signal is sent from the PC, routed through USB analyzer so it can read the signals as they pass through, and record the data to see what is being sent exactly, before going back out into the TUSB9261EVM. We don't have any analyzer capable of snooping between the TUSB9261 and the SSD.

Thank you for the explanation. I understand the setup now.

Ryan Kitto said:

In order to test with this SSD, because it is an M.2 NVME SSD, we have a SATA to M.2 SSD enclosure we are using in order to connect the TUSB9261 to the SDD, as we do not have any way to connect our TUSB9261EVM directly to the SSD. 

We are also using an adapter to convert the SSD to SATA in order to connect it to the TUSB9261, so the conditions should be the same.

Best Regards,

Yuya

Hi Yuya,

Okay, understood. I'll keep trying to see if I can get a proper trace if possible, to see if the host PC is properly communicating or not. I should be able to try the known good commands and see what those return as well. Ideally, we will see some activity over the USB lines, indicating the the commands are at least being properly sent out, that way we can compare between the two.

Thanks,

Ryan

Hi Ryan,

I think that's a good idea. I look forward to your efforts.

Best Regards,

Yuya

We are working on gathering the data now, we will have an update ready on 7/22

Hi Ryan,

Ryan Kitto said:

Okay, understood. I'll keep trying to see if I can get a proper trace if possible, to see if the host PC is properly communicating or not. I should be able to try the known good commands and see what those return as well. Ideally, we will see some activity over the USB lines, indicating the the commands are at least being properly sent out, that way we can compare between the two.

I was informed that there would be an update on the 22nd. How is it going? Could you please provide a status update?

Best Regards,

Yuya

Hi Yuya,

Sorry for the wait, I was out of office over the past few days.

I tried to gather some data with comparing a good command versus the failing command, here is what I have found so far:

When testing with the known good command: sg_raw -r 512 /dev/sdX a1 28 2d 52 00 00 00 00 00 81 00 00, this is what the analyzer sees. It looks like, from what I can tell, the command is being sent in transfer 0 here, and transfer 1 returns the data sent back from the SSD. The data provided in the analyzer matched what is returned on the linux OS, so I think that lines up. It looks like the command works as expected.

When testing with the failed command: sg_raw -s 512 –i set_auth.bin /dev/sdX a1 0a 25 00 00 00 00 00 00 81 00 00, this is what the analyzer sees. From here, it looks like transfer 0 and 1 look fine, with transfer 1 sending the data from the set_auth.bin file to the SSD. However, at transfer two, it looks like that's where the timeout is taking place, as you can notice that there is a 20 second interval between that transfer and the next which isn't present on the known good command. After that, it looks like the SSD may end up being disconnected temporarily, which prompts the linux system to request descriptors and other information from the SSD. So it seems to me like this command may be causing a disconnect of sorts.

I'm going to look into comparing these two a bit more to see if I can notice any other differences, or if there are any other signs of what might be causing this.

Thanks,

Ryan

Hi Ryan,

Understood. Thank you for your continued investigation, and I look forward to your findings.

Ryan Kitto said:

From here, it looks like transfer 0 and 1 look fine, with transfer 1 sending the data from the set_auth.bin file to the SSD.

Is it correct to assume that the TUSB9261 is properly converting the sg_raw command and sending it to the SSD, regardless of whether it succeeds or fails?

Best Regards,

Yuya

Hi Yuya,

Yuya Takashima said:

Is it correct to assume that the TUSB9261 is properly converting the sg_raw command and sending it to the SSD, regardless of whether it succeeds or fails?

I believe that is likely the case. It looks like the information is being sent through the TUSB9261 to the SSD properly. During that 20 second time, it seems like the SSD may either be freezing up or trying to configure itself, as I believe that's what the command is trying to do, before timing out and resetting. The other commands work fine though from what I can tell, so it may be this specific command that is causing the issue.

I'm going to try and see if there is any other information during this 20 second timeframe, potentially on the USB2 side or at FS/LS. Right now, the only main difference I'm seeing is that time out period on the failing command.

Thanks,

Ryan

Hi Ryan,

Ryan Kitto said:

It looks like the information is being sent through the TUSB9261 to the SSD properly.

Do you have any basis for this assumption? For example, using debugging tools to confirm the commands sent from the TUSB9261 to the SSD.

If the commands are truly being converted correctly and reaching the SSD, it would suggest that there is no issue with the TUSB9261. However, if there is any conversion error that causes the SSD to malfunction, it could indicate a problem. I apologize for being detailed, but I want to isolate the issue.

Best Regards,

Yuya

Hi Yuya,

No worries, it's better to be detailed and exact on this rather than just guess. I'm not the most experienced with decoding and analyzing these protocol traces, but I believe the best way to ensure these commands are being correctly received would be to look through the traces and look for acknowledgment, or ACK packets, which essentially tell the host PC that the device successfully received the information sent.

If I can look near when the command was sent and find this, then that would tell us that the command is being sent through and received by the device. I'll double check internally that this makes sense for confirming whether or not the command has been sent, or if maybe there is a better way of concluding whether or not the TUSB9261 is impeding this command or not.

Thanks,

Ryan

Hi Ryan,

Thank you. I hope we can achieve good results. If there are any updates or progress, I would appreciate it if you could share them.

Best Regards,

Yuya

Hi Ryan,

I have a suggestion. Would it be possible to check the command details and other information by debugging from the console? What do you think?

Best Regards,

Yuya

Hi Yuya,

I think it could give more results/evidence, though I'm not totally familiar with how the console could be used to debug this. What would be your idea for this? Trying different commands to see if certain commands cause this issue? Or is there a way for it to return more detailed info aside from just "finished" or "error"?

Thanks,

Ryan

Hi Ryan,
This is regarding your TUSB9261PvP, and I believe debug information can be obtained from pins 5 and 6.

The information should be as follows.

[2025-03-19 17:01:42.513] [0022969194] -> scsi_build_ata_pass_through_cmd() - cmd = 0x81, byte_cnt = 0, chk_cond = 1.
[2025-03-19 17:02:02.847] [0022989330] HS/FS/LS state = (0x5) EARLY SUSPEND.
[2025-03-19 17:02:02.847] [0022989331] USB Reset event occurred.
[2025-03-19 17:02:02.847] [0022989331] -> ahci_reset_lun(0)
[2025-03-19 17:02:02.847] [0022989331] -> ahci_fatal_error_recovery() - dev_status = 0x00000058, outstanding_cmd_slots = 0x00000000, force_comreset = 0.
[2025-03-19 17:02:02.847] [0022989331] -> ahci_port_reset(0)
[2025-03-19 17:02:02.847] [0022989337] @Error: ATA device busy! Re-initializing HBA.
[2025-03-19 17:02:02.847] [0022989337] -> ahci_init()
[2025-03-19 17:02:02.847] [0022989337] -> ahci_hba_reset()
[2025-03-19 17:02:02.847] [0022989343] SATA Gen-2 speed negotiated.
[2025-03-19 17:02:02.847] [0022989358] 
[2025-03-19 17:02:02.847] [0022989358] ================================================
[2025-03-19 17:02:02.847] [0022989358]              IDENTIFY DEVICE INFO
[2025-03-19 17:02:02.847] [0022989358] ================================================
[2025-03-19 17:02:02.847] [0022989358] 
[2025-03-19 17:02:02.847] [0022989358]   Model:  GBDriver GS2                            
[2025-03-19 17:02:02.847] [0022989358]   FW Rev: gs2.a100
[2025-03-19 17:02:02.847] [0022989358]   Serial: GS2000000T0000001630
[2025-03-19 17:02:02.847] [0022989358]   TRIM Support: Yes [DRAT][RZAT]
[2025-03-19 17:02:02.847] [0022989358] 
[2025-03-19 17:02:02.847] [0022989358]   Spec Compliance: ATA-7
[2025-03-19 17:02:02.847] [0022989358]   Removable Media: No
[2025-03-19 17:02:02.847] [0022989358]   UDMA Modes = 0x407f
[2025-03-19 17:02:02.847] [0022989358]   PIO Modes = 0x0003
[2025-03-19 17:02:02.847] [0022989358] 
[2025-03-19 17:02:02.851] [0022989358]   LBA48: Yes
[2025-03-19 17:02:02.851] [0022989358]   Max LBA = 0x00000000 5d28bb00
[2025-03-19 17:02:02.851] [0022989358]   Write FUA: Yes
[2025-03-19 17:02:02.851] [0022989358]   World Wide Name: N/A
[2025-03-19 17:02:02.851] [0022989358] 
[2025-03-19 17:02:02.851] [0022989358]   SATA Speed: Gen3
[2025-03-19 17:02:02.851] [0022989358]   NCQ Support: Yes
[2025-03-19 17:02:02.851] [0022989358]   Queue Depth = 31
[2025-03-19 17:02:02.851] [0022989358] 
[2025-03-19 17:02:02.851] [0022989358]   Logical Sector Size = 512 bytes
[2025-03-19 17:02:02.851] [0022989358]   Physical Sector Size = 4096 bytes
[2025-03-19 17:02:02.851] [0022989358]   Logical Sector Offset = 0
[2025-03-19 17:02:02.851] [0022989359] 
[2025-03-19 17:02:02.851] [0022989359] ================================================
[2025-03-19 17:02:02.851] 
[2025-03-19 17:02:02.851] [0022989361] Connected to 1 AHCI device(s).
[2025-03-19 17:02:02.851] [0022989361] -> ahci_reset_lun(0)
[2025-03-19 17:02:02.851] [0022989361] -> ahci_reset_lun(0)
[2025-03-19 17:02:02.851] [0022989361] -> ahci_reset_lun(0)
[2025-03-19 17:02:02.851] [0022989361] Connected at HIGH speed.
[2025-03-19 17:02:02.851] [0022989361] HS/FS/LS state = (0x0) ON.
[2025-03-19 17:02:02.851] [0022989417] HS/FS/LS state = (0x5) EARLY SUSPEND.
[2025-03-19 17:02:02.851] [0022989418] USB Reset event occurred.
[2025-03-19 17:02:02.851] [0022989418] -> ahci_reset_lun(0)
[2025-03-19 17:02:02.851] [0022989418] -> ahci_reset_lun(0)
[2025-03-19 17:02:02.851] [0022989418] -> ahci_reset_lun(0)
[2025-03-19 17:02:02.851] [0022989418] -> ahci_reset_lun(0)
[2025-03-19 17:02:02.851] [0022989425] Connected at HIGH speed.
[2025-03-19 17:02:02.851] [0022989425] HS/FS/LS state = (0x0) ON.
[2025-03-19 17:02:02.853] [0022989491] -> usb_hal_set_address() - addr: 0x3.
[2025-03-19 17:02:02.853] [0022989520] -> handle_usb_set_configuration() - val = 1.
[2025-03-19 17:02:02.853] [0022989525] -> ums_bot_case_handler() - case 5.
[2025-03-19 17:02:02.853] [0022989527] -> ums_bot_case_handler() - case 5.
[2025-03-19 17:02:02.898] [0022989570] -> scsi_build_ata_pass_through_cmd() - cmd = 0xec, byte_cnt = 512, chk_cond = 1.
[2025-03-19 17:02:02.898] [0022989571] -> ums_bot_case_handler() - case 5.
[2025-03-19 17:02:51.030] [0023037699] -> scsi_build_ata_pass_through_cmd() - cmd = 0x81, byte_cnt = 41472, chk_cond = 1.
[2025-03-19 17:02:51.030] [0023037702] -> ums_bot_case_handler() - case 5.
[2025-03-19 17:02:51.030] [0023037709] -> ums_bot_case_handler() - case 5.
[2025-03-19 17:02:51.030] [0023037712] -> ums_bot_case_handler() - case 5.
[2025-03-19 17:02:51.081] [0023037756] -> scsi_build_ata_pass_through_cmd() - cmd = 0xec, byte_cnt = 512, chk_cond = 1.
[2025-03-19 17:02:51.081] [0023037758] -> ums_bot_case_handler() - case 5.

Could you please review this internally?

Best Regards,

Yuya

Hi Yuya,

I see what you mean now, we do have that ability, yes. I can look into seeing if this would be helpful, I know I would need to modify our EVM in order to populate this jumper and monitor the UART TX/RX, so I would need to do that in the background to monitor this, as well as adjust the firmware if possible from our side to enable these debug messages.

That being said though, the information this offers us would primarily just be about the connection being made and the specs of the SATA/M.2 drive connected. I'm not sure it would provide much more data about the commands themselves, but it could still be good to grab as evidence later.

Thanks,

Ryan

Hi Ryan,

I see, understood. If it's possible to capture the data, it might be a good idea to do so.

The simplest way to isolate the issue, I believe, would be using a SATA analyzer. Do you have one available at your company? If you have any other suggestions for isolating the problem, I would appreciate it if you could try them as well.

Best Regards,

Yuya

Hi Yuya,

Got it, I'll go ahead and try to get that added onto our EVM to monitor. Maybe it'll tell us something about what is happening when these reset seems to happen.

Yuya Takashima said:

The simplest way to isolate the issue, I believe, would be using a SATA analyzer. Do you have one available at your company? If you have any other suggestions for isolating the problem, I would appreciate it if you could try them as well.

Unfortunately, our group does not have a SATA analyzer, nor do I believe we will be able to find one. I'll see if we have any other means of isolating the issue.

Thanks,

Ryan

Hi Ryan,

Ryan Kitto said:

Got it, I'll go ahead and try to get that added onto our EVM to monitor. Maybe it'll tell us something about what is happening when these reset seems to happen.

Understood. First, please proceed with the steps mentioned above, and thank you for your efforts. Additionally, if you have any good suggestions, it would be appreciated if you could implement them.

Best Regards,

Yuya

Hi Yuya,

Waiting on the EVM to come back from it's solder job for now, I'll let you know once I have it back and have tested the UART functionality.

Thanks,

Ryan

Hi Ryan,

Our company will be closed from August 9th to 17th, so I won't be able to respond during that time. If there is anything you can do, including obtaining debug information, could you please try it during that period?

Best Regards,

Yuya

Hi Yuya,

Yes, I will work on getting this testing done and feeding back the results I find in that time. Sorry for the wait.

Thanks,

Ryan

Hi Yuya,

I have the EVM soldered with the UART debug pins, and have been working on getting it setup with one of our other EVM's so I can see the debug output.

However, I am running into some issues on my end with configuring the serial port, so I am trying to get that figured out. I see data from the TUSB9261, so there is no concern there, it's just a configuration issue. I will continue working on this, and try to get an update to you on Monday, 8/18.

Thanks,

Ryan

Hi Ryan,

As we have passed 8/18, could you please provide an update on the progress?

Best Regards,

Yuya

Hi Yuya,

I'm still running into issues with getting the setup working as I expect it to, I've tried flash the software of both the devices I am using to try and complete these, but I am still seeing issues. I am going to look into the software aspect of the TUSB9261 to see if maybe I have the Baud rate settings wrong somewhere, as well as try different COM port boards.

A question I have from my side just to make sure I'm not missing anything, your group also used a baud rate of 115200 for reading from the debug of your board, correct?

Thanks,

Ryan

Hi Ryan,

Understood, we look forward to your update.

Ryan Kitto said:

A question I have from my side just to make sure I'm not missing anything, your group also used a baud rate of 115200 for reading from the debug of your board, correct?

Yes, we are using a baud rate of 115200.

Best Regards,

Yuya

Hi Yuya,

Got it, thanks for confirming. I will try to get this working so we can have more information as soon as possible.

Thanks,

Ryan

Hi Ryan,

Ryan Kitto said:

Got it, thanks for confirming. I will try to get this working so we can have more information as soon as possible.

It has been almost a week; I was wondering if there has been any progress in resolving the issue.

We had an opportunity to use a bus analyzer on our side, and I would like to share the results.

After examining the SATA protocol, the findings are as follows:

• The first image corresponds to the successful command.

• The second image corresponds to the failed command.

From the first image, it appears that the command along with the 512-byte data was sent correctly. In contrast, in the second image, the command plus 512-byte data does not seem to have been transmitted correctly.

Based on these observations, it seems that the TUSB9261 may not be converting the command correctly. What is your perspective on this?

Best Regards,

Yuya

Hi,

Ryan is out of office until tomorrow. He will have a response then. Sorry for the delays.

Hi Yuya,

I'm really sorry about the wait. I've been working on trying to get a working setup, and have been out of office the last few days for health reasons.

I'm not familiar with SATA protocol traces, so I can't say I know exactly what is going on here according to the screen shots you provided me. However, I do see that it does seem like the data is not getting through with the failed command. It's possible that the fail command is causing the firmware of the TUSB9261 to stall, but I can't say for sure. 

For the command being sent, would it be possible to help me understand what these values at the end of the command are meant to communicate/set: "a1 0a 25 00 00 00 00 00 00 81 00 00".

"sg_raw -s 512 –i auth_device.bin /dev/sdX a1 28 2d 51 00 00 00 00 00 81 00 00"

"sg_raw -s 512 –i set_auth.bin /dev/sdX a1 0a 25 00 00 00 00 00 00 81 00 00"

For example, for the two commands above, the primary differences are the files being sent, and the associated command parameters. It's my understanding that both commands above are sending 512 bits of a .bin file, with the op code a1 acting as a passthrough op code. However, what are the differences in the CDP between these two commands that may cause this issue? Is it possible to use the first command with the set_auth.bin file?

If you have additional details about the commands being sent, or somewhere I can study the format used for these sg_raw commands and what the command parameters being used mean, I would appreciate it. I'll keep working on getting the TX/RX setup working as well, I'm not sure why it's giving such a headache.

Thanks,

Ryan

Hi Ryan,

sg_raw -s 512 –i set_auth.bin /dev/sdX a1 0a 25 00 00 00 00 00 00 81 00 00

is intended to enable a function present on the SSD. The file set_auth.bin specifies the details for enabling this function. Therefore, even if you were to send auth_device.bin with this command, it is unlikely to work correctly. And even if it did, the details would be different, so set_auth.bin must be used.

On the other hand, the command:

sg_raw -s 512 –i auth_device.bin /dev/sdX a1 28 2d 51 00 00 00 00 00 81 00 00

is meant to be sent after the function has been enabled. It returns 512 bytes of data reflecting the current state of that function, as specified in auth_device.bin. If the function has not been enabled, it will return 512 bytes of seemingly random data.

For more detailed information about these commands, searching for sg3_utils should provide various helpful references.

Best Regards,

Yuya