FW v70 libusb issue #147
Comments
|
Sorry @Trevelopment I don't know C++... :( |
|
I haven't tried on the new FW but just looking at your logs and the code maybe this is a clue: The failing version is saying that it's trying to write to an invalid device, but I noticed that they pick different endpoints. Endpoints are like of like ports if we were doing TCP so the code is listening on 0x81 in both, but writing on 0x2 in the working one and 0x1 in the failing one (iusb_ep_in and iusb_ep_out). This is weird since the device (eg the phone) defines these, so they should be the same assuming you are using the same device each time. The code searches through all the ones it enumerates to find the correct one (the bulk transfer stream) at https://github.com/gartnera/headunit/blob/master/hu/hu_usb.cpp#L502 Maybe this code is buggy and the exact layout of enumeration list is different now so we are seeing the bug? For one I could see that https://github.com/gartnera/headunit/blob/master/hu/hu_usb.cpp#L521 should be Maybe libusbx adds more of these flags so we can't just test against 0? Or maybe when it's looping over the libusb_interfaces in the outer loop we need to filter somehow and before we were just getting lucky that the right one was first? Maybe dumping out the entire libusb_config_descriptor in both cases (or even just PC vs v70 since PC works) would reveal what we are doing wrong since it should be choosing the same 0x81/0x02 endpoint in both cases I think. EDIT: Also we are always getting the 0th config, we could call libusb_get_active_config_descriptor instead or repeatedly call libusb_get_config_descriptor until it fails increasing indexes to get all of them. I'm not sure how to filter them though. EDIT2: 😄 Wait I see now, we probably need to loop over the configs until we find the one with bDescriptorType == LIBUSB_DT_ENDPOINT, maybe it's not config 0 anymore. |
|
By the way I haven't following development on this for a while but, for really good performance you should use 2 separate threads one which reads and one which writes. AA actually works on multithread so for a nice performance you should really use 2 separate threads. Not sure if this proves as already implemented or not. |
|
@borconi we actually do, there is usb_recv_thread_main which is a dedicated thread to receive the usb data and put in the pipe to the HU thread. I was hoping it would help with stuttering, but it didn't. 😢 But you are right it is more efficient and for the rest of the code reading from a pipe is simpler than using libusb (and also abstracts the difference between WIFI and USB) |
|
@Imagder I'll post here my Java class I'm using. My latest headunit reloaded really flies. I use a main thread for reading and a few more others for processing and sending. So the main thread reads one message (abstract from TCP or USB) looks at the header and pass it to a spearate processor based on the header. For example if it's audio I have an audio processor, which sends back an acknowledgement to the phone and then hands over the audio data to another thread which is processing the audio, same with video data, video is processed on yet another thread, GPS is running on a system and I have a listener which then sends GPS data to car but again that's a separate thread, so idea is that each action has its own thread that way there is no shuttering what so ever. Hope it makes sense. If you want the full source code (pure java) send me an email to [email protected] happy to email it over for referencing (it's not on GitHub) |
|
@lmagder I don't understand your logic here |
|
I'm having trouble following this issue... @Trevelopment what was changed? |
|
Hey this is all good stuff thanks @lmagder I knew you would point me in the right direction. @GrayHatter On v70 FW AA doesn't start up it just crashes over and over again with the output in the first post. I think its a libusb issue Im gonna try what @lmagder said to do and see if that works. @borconi is your headunit reloaded designed to run on another android device or a raspberry pi? How tough do you think it would be to rewrite it to work on the MZD CMU? I am pretty proficient in Java at least more than I am at C++ that's for sure and at this point I know the integration parts pretty well I may even be able to write them in Java from scratch. Anyways I set you an email. |
|
does java even run on the mazda IVI? |
|
@GrayHatter No I don't think Mazda units run Java out of the box, and to answer @Trevelopment my app is for other Android devices. OpenAuto might be another good point of inspiration: https://github.com/f1xpl/openauto or CranckShaft https://github.com/opencardev/crankshaft both builds should run on Raspberry Pi, which means it should work on the Mazda as well. |
|
You can compile Java using the m3 toolchain POC is the Screencast Receiver so theoretically if you put in the CMU specific code you can compile and run headunit written in Java. I may explore that but it might still be a lot of work. |
|
So trip on this, I made a few changes based on your suggestions @lmagder and now it looks like it is about to almost work: So what changed? I am not getting the [op_release_interface] error anymore now I see the common [do_close] errors that I have seen before so the device was connected for a quick second. but even though iusb_ep_out didn't change it looks like it is about to start working so it seems like I am going in the right direction. I guess I just don't understand the endpoints completely but I feel like I am getting close. |
|
@Trevelopment I'm not sure that would help, we're not actually using the version of libusb in the m3 toolchain (btw I turned on issues, not sure what was up with that) at runtime. It uses the libusb.so on the car, we are just using the function definitions in libusb.h to build our code so as long as the function names, parameters, struct members, etc are the same it should work. Libusb is designed so that they don't randomly change stuff in incompatible ways since that would break programs on your Linux PC when you upgraded so they might add new stuff, but wouldn't change or remove old stuff. So like for example, that's why I was wondering about the (ep_add & LIBUSB_ENDPOINT_DIR_MASK) == LIBUSB_ENDPOINT_IN code. It's possible that the libusb on the car might have additional flags (that we don't care about) that it returns that aren't in our header or any header we have access to. The standard libusb (so far at least) defines
but later they could add something like
That would make our test against 0 (since LIBUSB_ENDPOINT_DIR_MASK == LIBUSB_ENDPOINT_IN EDIT: Sorry I got kind of rambling 😄 but my point was yeah I think your approach of going over the code carefully and making sure we handle all the weird cases and use the libusb API 100% correctly without assuming anything is probably the best approach to fix this but also keep it working on the old CMU version. |
|
Also, from your log, it seems like it's falling into the else case of https://github.com/gartnera/headunit/blob/master/hu/hu_usb.cpp#L254 when finishing the first read. Maybe the status is something other than LIBUSB_TRANSFER_COMPLETED or LIBUSB_TRANSFER_OVERFLOW and we need to handle that case too now This might help explain more about the libusb transfer object and how it works: http://libusb.sourceforge.net/api-1.0/group__asyncio.html |
|
Thanks I was totally looking at that sourceforge page already for reference. The transfer errors that were coming up before were LIBUSB_TRANSFER_NO_DEVICE but now they are just LIBUSB_TRANSFER_ERROR so thats an improvement I guess but I will keep looking over the code trying different things. |
|
Hello! Today I did the serial procedure with also v70 and tried with Android Auto from AIO. Sound doesn't work but touch yes. A minor bug is that home button is on the right. I'm a computer science engineer and I would love to help, but I need some guidance... Thanks to the devs that made this possible! |
Same here. Do you have the updated usb hub for AA/carplay? My car has the official AA upgrade but the AA does not allow touch screen and no AA-HUD integration either. Updated my firmware to v70.00.335 and it is the same. |
|
Wait you guys are able to get this to work at all on 70+? |
Just went through the code again... but could you tell what were the changes that made the code to start the ssl handshake? |
|
Was there any code changes to fix this? I just built a copy, and statically linked in libusb 1.0.15.10646, and it seems to work. Might just need it upgraded in our toolchain. |
|
@silverchris , is the toolchain updated now? I can see this version in readme here silverchris/mazda3-build-tools@77e43bf in mazda3-build-tools repo. Your commit on the same day as your comment here. |
I have been testing on v70.00.100 without the upgraded USB hub and I narrowed down the issue to an updated version of libusb (actually it changed to libusbx, a fork of libusb). Could someone with knowledge of libusb take a look at this?
Or it could possibly be the ssl handshake that is failing?
here is what happens when you try to connect on v70 (libusb_get_version: version: 1.0.15.10646):
For reference this is the log when AA opens on any lower FW version and just to make sure I used v59.00.545 (libusb_get_version: version: 1.0.9.0):
The text was updated successfully, but these errors were encountered: