libticables slv_bulk_read timeout

[ghost]

Sort of getting desperate here.

I've tried to get tilp to work on OSX, Win and Linux today, and still haven't succeeded. The ultimate goal is to install KnightOS. On OSX and on Linux I managed to get tilp to connect to the calculator (TI 84+, boot code 1.02; OS 2.55MP), but as soon as I try to dump the ROM (both via double click on operating system and via Tools->dump Rom), I get a slv_bulk_read (Operation timed out) error. Any ideas?

This has happened on OSX Mavericks, and ArchLinux, with tilp 1.16 and 1.17 and the newest libticables from the AUR.

[debrouxl]

Well... ROM dumping has just worked for me on a 84+SE, through both SilverLink and DirectLink, and the two ROM dumps are identical. The host computer is running Debian sid. That's not to say that nothing can be wrong with libti*/tilp, just that there's nothing obvious, as all of the pieces can work, AFAICS :)

Out of habit, I'm using a timeout value of 50 (5s), which is higher than the default. However, for the purposes of ROM dumping, there's no moment where the communication is paused for anything close to 5s. Also, did you trigger a dirlist before attempting to dump the ROM ? I doubt that this can help, though.

A possibly noteworthy difference between your tests and my tests, is that I intentionally stick to using the libusb 0.1 backend for libticables. Debian and derivatives (which many libti*/tilp users use) keep providing a working libusb 0.1.x (alongside libusb 1.0.x), while on the vast majority of other distros, including Arch, libticables needs to be built against libusb 1.0 proper (--enable-libusb10, as indicated in install_tilp.sh). Indeed, the 0.1 compat layer for libusb 1.0 provided by most distros does not work for the purposes of libticables.

EDIT: oh, and on Windows (which version and type, BTW ?), did you ever install TI-Connect before attempting to install TILP II 1.17 ? In that case, you need to follow the manual procedure described in the README for installing the "filter driver", whose goal is to work around a fundamental limitation of Windows, which positively hates having more than one possible driver for a given piece of hardware. No such user-inconveniencing silliness on well-behaved OSs.

[ghost]

I did trigger a dirlist, without that I get some other error (namely "Invalid packet", and upon trying again a "Unable to reset USB device; errno=19)". But that doesn't seem to be the main issue.

About libusb0.1, so you think it might be worth it to try it on a ubuntu machine?

Yup, changing the timeout didn't change anything.

Another difference might of course be my TI, it's been through some rought years. Shaking it slightly makes noises as if there were some loose parts in there, so I'm going to blame that for the moment^^

I might be able to get a colleague of mine to lend me his TI for a test dump, so I'll report back after that has happened.

[diabl0w]

I know this is old but I am suffering from the same or very similar bug. However, I know exactly what is happening, I just don't know how its happening.

First, I am on Linux, using a Silverlink Cable, with a TI 83+ calc.

Second, I can confirm it is an issue with the "v2" versions of the tilibs. If I use your new tilp but disable the version checks, and use the previous versions of the tilibs (every lib is 1 version lower), everything works fine.

The issue is not triggered by getting a DirList, and not by transferring small files. The issue is specifically trying to transfer larger files to the calculator.

Here is where it gets interesting:

ticalcs-INFO: 02:30:27.838:  PC->TI: RTS (size=0x1932=6450, id=06, name=CHESS, attr=0)
ticalcs-INFO: 02:30:27.856:  TI->PC: ACK
ticalcs-INFO: 02:30:27.885:  TI->PC: CTS
ticalcs-INFO: 02:30:27.885:  PC->TI: ACK
ticalcs-INFO: 02:30:27.886:  PC->TI: XDP (0x0032 = 50 bytes)

(tilp:91531): ticables-WARNING **: 02:30:32.891: slv_bulk_read (Operation timed out).

Here you can see that the transfer stopped after 50 bytes. In the old working version, the part that says 50 bytes will instead 6450 bytes, matching up to the full file size that is noted a few lines above it. Did you notice something interesting about the hex representation of those bytes? Yes, they are the same except the transferred version has 0x00 at the big end. This is further confirmed by trying to transfer a different file:

ticalcs-INFO: 03:13:12.558:  PC->TI: RTS (size=0x041E=1054, id=06, name=DOCDE7, attr=0)
ticalcs-INFO: 03:13:12.580:  TI->PC: ACK
ticalcs-INFO: 03:13:12.596:  TI->PC: CTS
ticalcs-INFO: 03:13:12.596:  PC->TI: ACK
ticalcs-INFO: 03:13:12.636:  PC->TI: XDP (0x001E = 30 bytes)

(tilp:129505): ticables-WARNING **: 03:13:17.640: slv_bulk_read (Operation timed out).

The 0x1E is preserved, but the 0x04 was dropped

[diabl0w]

I guess technically unrelated to original issue because I found the problem which is this commit.

Reverting it resolved the issue

[adriweb]

Yes it's my fault in this commit, the length parameter needs to be a uint16_t for the ti*_send_XDP functions. Easy enough to fix.

[diabl0w]

Yes it's my fault in this commit, the length parameter needs to be a uint16_t for the ti*_send_XDP functions. Easy enough to fix.

I ended up finding that too, but when i made the adjustment to uint16_t, it didn't seem to fix the issue. but it could definitely be just because I am struggling to get clean builds. I'll try to test again

[debrouxl]

Thanks for the report, diabl0w. Adriweb and I discussed this elsewhere this morning, but neither of us followed up here before you came to the same conclusion as me.

[diabl0w]

okay i can confirm changing all of the tiXX_send_XDP unint8_t length to uint16_t does work. Im still a bit confused, because I originally just changed the ti82_send_XDP to uint16_t length, but that didn't work. Maybe the TI83+ uses the TI73 call? not sure. just to scratch my curiosity, i'd appreciate if either of you were able to explain why changing the ti82 only didn't work

[debrouxl]

Right, the 83+ code uses ti73_send_XDP().

[adriweb]

There were a few other mistakes, https://github.com/adriweb/tilibs/commit/83246f6182ab565104688455b86a86503df940bd should fix them. I'll let @debrouxl review #86 and integrate it, I guess.

[debrouxl]

First part integrated yesterday, with an additional fix.

[diabl0w]

First part integrated yesterday, with an additional fix.

Thanks, im really surprised the compiler doesnt catch this. I am not a super experienced programmer, but I do have some programming history and typically it wouldnt even let me compile doing something like this. If i wanted to do it on purpose for some reason, i would have to cast it just to compile succesfully.

Off topic, but id appreciate the help: What is the preferred method of compiling this with tilp? Specifically for the gtk3 branch. Ive been using a modified version of the bundled .sh script but it seems a bit hacky. I have 0 understanding of cmake so i tried to use it but failed pretty quickly.

Edit: On Linux

[adriweb]

Regarding the build with cmake, you can see how the CI does it in the GitHub actions workflow. It should be pretty straightforward, and even requires less deps than with the autotools.

[diabl0w]

Regarding the build with cmake, you can see how the CI does it in the GitHub actions workflow. It should be pretty straightforward, and even requires less deps than with the autotools.

oh wow thats a huge help. ive been meaning to look into what all this github action/workflow stuff was... thank you.

Also, looking into some c documentation, i may have been wrong about the compiler. i think C may be happy to convert int16 into int8 and just overflow it without warnings. not too sure tho

[debrouxl]

Adriweb mentioned that the original reporter's account was deleted, which I missed. Closing the issue as it's unlikely that we'll get a reply.