yashsingh1/xdaforums huggingface dataset:
[Android Head-Units] donaldta:
It might depending on the your measurement tools. USB operates on a digital differential signaling. This means it a series of on and off pulses which mirror each other between Data+ and Data- pins. For example a differential "1" is transmitted by pulling Data+ between 2.8 to 3.6 Volts with a 15K ohm resistor pulled to ground and Data- between 0.0 to 0.3 volts with a 1.5K ohm resistor pulled to 3.6V. A differential ‘0’ on the other hand is a Data- with 2.8 to 3.6 Volts and a D+ between 0.0 to 0.3 volts with the same appropriate pull down/up resistors.

However, this happens very quickly and most multimeters cannot pinpoint the fluctuating voltages. At best, it might show you the root mean square. Normally, people use either a Logic Proper or a Mixed Signal Oscilloscope for measuring digital signals. Multimeters are better used for analog voltages, resistance and current.

Another possibility is that it is a Transistor-transistor Logic (TTL) type Universal Asynchronous Receiver and Transmitter (UART) which I brought up earlier in Post #96 with the article, "Reverse Engineering Serial Ports" article that I had pointed out earlier.

Seriously? I had already noted that earlier in Post #163 and Post #178.

That's probably due to the printed circuit board and how they designed the components to be soldered on the board. The more interesting observation as pointed out in Post #178 is that there are only two traces from the CPU going to it not four. According to aplusmiami in Post #189 there is a Standard Microsystems Corporation (SMSC) USB2513Bi microchip which is a USB 2.0 Hi-Speed Hub Controller. Do any of its traces go to any of the external USB ports?

Really? aplusmiami already pointed that out in Post #148 when he first posted pictures of the top circuit board and in Post #189 when he drew up the diagram for his connector for the beige socket. I even pointed that out in Post #178 when I wrote, "I would suspect the 4 pin beige connector to the right of these cables is actually the USB OTG connection and is set to be a simple USB peripheral header. "

Actually, I dug a little deeper into the USB guidelines which indicate that the shielding should NOT be connected to USB Ground. The shielding is normally connected to the "chassis" ground or a drain pin. I guess since those external cables aren't physically touching the chassis on the back, so the 5th pin on the connector is the drain pin.

I found a simplified article that points this out in layman terms, "USB Made simple: Part 2 - Electrical since it seems nobody here reads the more technical references that I link anyways.

That looks like a Japan Solderless Terminal (JST) connector. You might want to measure the distance between pins to get the correct connector because they range from 1.00 mm to 3.96 mm in spacing.

Is there another processor on that I/O logicboard? If so it could the MicoProcessing Unit (MPU) which handles the individual components for the Android board.
[Android Head-Units] siralsmooth:
It's entirely possible that the connector on the side is exclusively for diagnosing the audio board. I hadn't really thought of that. I just don't see that if a unit is sent in for a bad android flash, that they would take it apart to reflash the system. Anything is possible though.
[Android Head-Units] aplusmiami:
To clear things up a bit:

(SMSC) USB2513Bi) the traces appear to connect to the header that has two USB external ports. These external connections are labeled USB and the other Wi-Fi receiver with a USB Wi-Fi dongle. It is safe to assume these are the two USB 2.0 connections.

The other USB header appears to be connected directly to the CPU. This external connection is meant for an iPod and I am assuming is USB 1.0.

The green wire (5th wire) is the drain/shield connection. At least that's what my meter says.

So it looks like the beige connector is our USB 2.0 OTG connection.

The beige header is accessible through the heat sink and it only takes 4 screws to remove the cover of the radio.It makes sense that this would be some sort of service port.

I am a little afraid of that 5V connection (RED). But will give it a try as soon as I can find a connector to fit that header. I am searching through a pile of dead notebooks I have.
[Android Head-Units] donaldta:
Are you taking a piss? The green wire shouldn't be a drain/shield connection. The green and white wires have to be data pairs. The whole reason why the green and white wires are twisted together is to reduce crosstalk. One of the black wires should be the shield/drain connection. Also, don't get caught up by the sequence of the pins on the circuit board because that can appear in any sequence. The important thing is where they end up on the connector otherwise USB cannot communicate.

From the previous feedback from chris.davis925, I would suspect the actual configuration is

Vcc - 5VDC

Data-

Data+

Ground

Drain

And would look like this.

Also, my experience with head units which supply a dedicated USB port for "iPod", the main difference is that the Vcc is rated for 2A to allow charging for various iOS devices because the standard USB 2.0 port is maximized at 500mA which is shared with the other ports.
[Android Head-Units] aplusmiami:
Sorry had a brain fart - the one of the blacks wires is indeed the shield/ground...

Not the green...

What I'm getting at is these are not the OTG connections because they go to the chip not the CPU...

The only other connection not populated is the beige connection physically located on the Mobo..
[Android Head-Units] chris.davis925:
I want to point out that the single USB connector (which is the one for iPhone / apple devices) must have something more to it than just more amp ability, because I can't get any USB sticks to work on that port. USB accessories (besides iphone) appear to only work when you use the the connector with the 10 wire USB connection.
[Android Head-Units] aplusmiami:
The iPhone connection is not usb2 so if the stick you are using is usb2 it will not work. Plus I remember reading in the manual somewhere that you should use the other USB connection for firmware updates and reading USB devices.

---------- Post added at 02:49 PM ---------- Previous post was at 02:46 PM ----------

Also my post about the type of ports and their locations is in theory. I don't have a schematic and have limited specs.
[Android Head-Units] chris.davis925:
I ordered various JST connectors/wires from sparkfun.com. It should come in tomorrow.
[Android Head-Units] chris.davis925:
In my unending desire to root (or at least install APKs on this DNN device) I researched some more ways to possibly obtain root access.

Have you guys heard of the Android WebView exploit? There is an example here: http://packetstormsecurity.com/files/125113/Android-Browser-WebView-addJavascriptInterface-Code-Execution.html

I never paid much attention to it because it was my understanding that a non stock application (that is not the browser) had to be present and use WebView in order to the exploit to work and I wasn't aware of any on the DNN990. I found out that the Youtube app invokes what appears to be "WebView" for displaying a google sign in page. From there you can actually redirect to google.com, which then makes it so we can visit any web page - all from within the Youtube app's "WebView" instance.

Again, attempting anything here is outside of my current knowledge since I do not have a background in Linux or Java - but if I am understanding correctly, if you we redirect the WebView invoked browser to a web page we setup, we can then inject .js (somehow?) and make a call to Java in Android which would lead to things like running commands via a .sh script. If my understanding is correct, I suspect we could use this to somehow enable ADB over WiFi or at the very least enable the "Install from Unknown Sources" setting?

Let me know if I am way off here. If the above logic is somewhat correct, I would need some help with how to move forward with attempting this kind of exploit.

Update:

Here is another link that I think is explaining a similar way.

https://labs.mwrinfosecurity.com/blog/2013/09/24/webview-addjavascriptinterface-remote-code-execution/
[Android Head-Units] donaldta:
Very interesting exploit. Unfortunately, it is outside my personal expertise and comfort zone as well. Though, from what I can tell the exploit has to be served like a web page. Technically, you're not "injecting" javascript code into the page. The javascript exploit is hosted as part of the actual webpage that you're directing WebView to read / execute it.

Also, Javascript has nothing to do with Java despite the similarity in namesake. That's like saying Hamburgers or Hamsters are in some way relative Ham.
[Android Head-Units] aplusmiami:
Found a connector that is close. I trimmed the sides and it fits. I will solder things up tonight and see what I get.
[Android Head-Units] chris.davis925:
I can confirm that the wires that I bought that came in today do fit perfectly into the side panel and also the motherboard. I'm going to try and create cable right now I just wanted to write you guys been updated. Although what exactly I do once I get the cable is another story ....

---------- Post added at 02:18 AM ---------- Previous post was at 01:34 AM ----------

This is what I found.

The four pins on the board. 1st pin being the one closest to the front screen.

1st pin: Ground

2nd pin: 3.25 Volts

3rd pin: no reading

4th ping: no reading (but does shows very low negative amperage in mA)

On my PC, I cut off a USB wire and meassured the voltage. I found the 5v wire as expected. I have a noob question.... is it okay to plug in the USB power wires to each other, even though they are both emitting voltage? Doesn't seem right?

---------- Post added at 03:16 AM ---------- Previous post was at 02:18 AM ----------

On the second beige connector on the android board (not the connector we think is a USB OTG)

1st pin : ground? (Registers nothing)

2nd pin - 3.3v

3rd pin - 3.3v

4th pin - ground? (Registers nothing)

---------- Post added at 03:17 AM ---------- Previous post was at 03:16 AM ----------

Beige side pin (which apparently some units don't have has the same readings, as follows:

1st pin : ground? (Registers nothing)

2nd pin - 3.3v

3rd pin - 3.3v

4th pin - ground? (Registers nothing)
[Android Head-Units] aplusmiami:
Are you sure the second beige connector you are referring to is the one in the side?
[Android Head-Units] siralsmooth:
When you did the measurements, did you do them with the radio powered, or powered up and on?

Sent from behind your couch while chillin with the Boogeyman!
[Android Head-Units] chris.davis925:
The last "beige" connector readings (which are identical to the second readings I listed) are in fact from the side part of the unit.

---------- Post added at 06:53 AM ---------- Previous post was at 06:52 AM ----------

All of the readings where from when the radio was fully powered up and working.

The only other test I did was with the unit off (as in the car was off) and as expected, no readings from any of the ports.

I did not test the readings when the unit was powering up or in standby mode.
[Android Head-Units] chris.davis925:
How did your testing go?
[Android Head-Units] aplusmiami:
Unknown Device!!

Well I connected everything to the 4 pin beige connector on the mobo (Motherboard) and I am getting an unknown device... what now?
[Android Head-Units] siralsmooth:
Try installing the drivers for a galaxy nexus phone. The build keys/version info seems to be the same when I googled it way back. Check for yourself. Worth a shot.
[Android Head-Units] aplusmiami:
Update: I swapped Data - / + and now I get a device!!!!

Under Disk Drives:

2 Entries that are identical

Linux File-CD Gadget USB Device

Linux File-CD Gadget USB Device

Got the give the babies a bath... So I will return... Any insight unto what to try next?!
[Android Head-Units] siralsmooth:
Try adb shell or terminal and see if you can connect.

On second thought, Garmin uses Linux. When connected, press the navigation button and see if the option to get into mass storage or Garmin mode is available. Might be the port to load stuff to the Garmin drive.

Sent from behind your couch while chillin with the Boogeyman!
[Android Head-Units] chris.davis925:
Try ADB.

Also, can you confirm the exact pins you connected to which USB wires?

---------- Post added at 07:25 AM ---------- Previous post was at 07:24 AM ----------

Also, did the deck report itself as having a USB device plugged in? Did it give you the option to select which USB mode?
[Android Head-Units] aplusmiami:
I tried adb devices and no devices found

---------- Post added at 02:39 PM ---------- Previous post was at 01:52 PM ----------

I don't see anything in the Nav section indicating anything that allows me to mount anything via USB

Under USB SD - No Device

Under Software Setup with the Unit On/Off Update buttons are greyed out

I've read a little last night that we need to somehow replace the Linux File-CD Gadget USB Device with drivers that ADB can see... Apparently this configuration is one step away from us possibly getting ADB to work. But we need a usable com port.

I can only work on this at home - Boss got me under the microscope at work so I do want to rock the boat. Send me some more suggestions.. to try this evening.

---------- Post added at 02:43 PM ---------- Previous post was at 02:39 PM ----------

PIN OUT - 4 Pin Beige Connector on Motherboard

Pin 1 (Close to LCD) Ground USB Black

Pin 2 USB White Data +

Pin 3 USB Green Data -

Pin 4 USB Red +5VDC
[Android Head-Units] chris.davis925:
Sorry I don't mean to ask again... but are you sure that's how you have it plugged in? I plugged my connector exactly as you have stated and it doesn't work. Windows actually disables the USB device because it detects a problems. That would make sense to me too, because when I measure one of the pins which you state is data, I get 3.3 V.

So I want to clarify again. Can you confirm how you have it plugged in?

Also, can you clarify that you are plugging it into the beige connector that we have earlier guess is the USG OTG connector? In other words, NOT the side panel beige connector and NOT the beige connector that doesn't have the two data leads visible going to the USB CPU?

Thanks

Update: Maybe a better way to ask this question is... what readings do you get form the beige connector when using a voltage meeter? Is it the same reporting that I found?
[Android Head-Units] donaldta:
You should probably let the others know which one(s) you purchased from Sparkfun that fit.

PRT-09240: JST ??, 4 wire, ?.?mm pitch

PRT-09916: JST PH, 4 wire, 2.0mm pitch

PRT-10359: JST SH, 4 wire, 1.0mm pitch

I'm guessing it is not the PRT-10364: JST RE, 4 wire, 2.54 pitch since that seem too large for this application based on your previous feedback on the connector's size.

Well, yes and no. A USB peripheral should not be supplying any voltage on the VBUS line. Try thinking of it as you were connecting a USB Flash drive which has no power. The idea is that it is going to accept the voltage from the USB host or provide its own. If it did supply its own ~5VDC then and put it on the VBUS you would have 10VDC running between the wire which would probably burn out the wire and/or circuitry. The negative amperage is a good sign that it is the USB VBUS line for a peripheral.

I am curious if the side connector on the lower board is an extension of the other one on the CPU board. Have you checked for continuity between the pins of the two connectors? I'm thinking there's (at least) two revisions of this model and maybe the side pins were added or removed because of its "convenience". The possibility is still open for these connector to be either a JTAG or Serial port but can be probably can ruled out as a USB port.
[Android Head-Units] chris.davis925:
1) The JST connector that fits this board is this one:

https://www.sparkfun.com/products/10359

2) In regards to the beige connector (which we think is the OTG) can you elaborate a bit further what exactly the results of the 3.3v readings indicate? Is this expected? if it is, is it expected that the way that previous guy hooked it up would work?

I am almost wondering if the different revision boards that we have change how the ports work all together...?

---------- Post added at 08:07 PM ---------- Previous post was at 07:43 PM ----------

Try to install these drivers. : http://depositfiles.com/files/29d02mji2 They are for the TCC8803, but with any luck they will work for TCC8801.

Update: Found what MIGHT be generic TCC ADB drivers. Not sure the source, but it's worth a shot: http://www10.zippyshare.com/v/38212722/file.html
[Android Head-Units] donaldta:
Well, I would do a couple of things. First of all, go into your device manager to check if there are any other added devices when you plug it into the USB port. An easier way of figuring it out in Device Manager is to select View > Devices by Connection. You will have to drill down a few paths to find it. When you plug in an Android device it should come up as a "USB composite device" as the root connection into the hub. Then the individual USB components should appear below it depending on the drivers installed.

The above is an example of my Nexus 4 after the ADB drivers were installed. The "Android Composite ADB interface" before the drivers were installed was an "unknown device". The component below it is the internal sd flash memory partition (the /mnt/sdcard path of the Nexus 4).

I suspect that in your case, the two "Linux File-CD Gadget USB Device" are your Media Transfer Protocol (MTP) devices for the internal and the "external" (physical) micro SD Card. Hopefully you have a third device for the Android Device Bridge (ADB) connection. That will be the device that you would manually apply the ADB drivers that I've included in this post at the bottom.

Btw, when you look at your "My Computer" folder do you have extra "devices/drives" available to you while the DNN is plugged in? If not then maybe try using Disk Internals' Linux Reader to mount them.

That is to be expected if you have not installed the ADB drivers yet.

You actually wouldn't replace the "Linux File-CD Gadget USB Device" with the ADB drivers as those are separate components. Because the "Linux File-CD Gadget USB Device" should be representations of certain partitions that are mounted on linux.

:good:

EDIT: also added the Telechips drivers and VTC from the drivers.rar file from "depositfiles" that chris.davis925 linked in the previous post. I didn't include the PdaNetA245.exe or the SAMSUNG_USB_Driver_for_Mobile_Phones_x86.exe because I didn't think it was actually relevant. The files from the "Zippyshare" are a duplicate of the drivers within drivers.rar file from "depositefiles".

The usb_driver.zip file comes from the Android Developers Toolkit which was created from the following path, "\20130729\sdk\extras\google\usb_driver". These are generic ADB drivers which may not have the VID/PID references of the USB device in the .inf file, so it has to be manually "forced" installed when Window doesn't think it applies.
[Android Head-Units] donaldta:
Okay, that's good to know then its a 4 conductor JST-SH which has a 1.0mm pitch between the pin's center. This description will make it easier for other people to source the correct connector from other places other than SparkFun (which for some in other parts of the world might help to avoid needless export fees and taxes).

Well, it actually depends on the USB port state at the time of measurement; as well as, the accuracy and the response time of the measuring tool. Data lines are not pins that you can reliably measure with a voltmeter. Not sure why but it seems like I've communicated this several times in my past responses, and I am pretty sure that I have already linked several articles which discuss the electrical properties of "data" pins for USB, TTL, and JTAG ports.

It is definitely a possibility.
[Android Head-Units] aplusmiami:
Plugged into the beige connector that is not populated on the Motherboard/CPU Board. It is a 4 pin connector...

---------- Post added at 02:33 AM ---------- Previous post was at 01:52 AM ----------

There is no USB composite Device. and the I tried to access using DiscInternals No go
[Android Head-Units] chris.davis925:
I feel so dense right now, but you totally threw me off. You stated NOT the beige connector on the CPU board. The only beige connectors I'm aware of are the two on the CPU motherboard and the one side panel board.

Sorry if I am just an idiot and aren't understanding correctly but would you mind taking a picture (or circling a previous procedure) to show exactly what beige connector you are talking about?

It would also be fantastic to see your volt meeter reading for this connector. Thanks!!!

---------- Post added at 12:53 AM ---------- Previous post was at 12:48 AM ----------

I did look over all links you sent. That's why I asked my question. It seemed to me logically that having 3.3v from the deck plus 5v from the USB host computer didn't seem right. But yet, it seems the other forum user has successfully gotten USB to work by using a pin that I meassured 3.3 volts on as a data pin, which from the articles you posted, doesn't make any sense to me at all. This is why I'd like to know what read outs he is getting on his meeter with the beige connector.

I also bought the BUS pirate per one of your recommendations though I mist admit, I have zero knowledge on how to use it.
[Android Head-Units] donaldta:
Remember, you two have different board revisions. Some soldering points are populated with connectors while others are not between your separate units. Perhaps it would be better if you guys refer to the connector by its silk screen labeling. Afterall, that's it what's it there for. The "USB OTG" we are all referring to is the CN902 connector that both of you have. The board chris.davis925 also has the same 4-pin JST-SH on the CN102 which on aplusmiami's is unpopulated.

Interesting. Would you mind showing us a screenshot of your Device Manager with the View > Devices by Connection selected and the respective Android USB device showing?

---------- Post added at 07:45 PM ---------- Previous post was at 07:04 PM ----------

A USB device must indicate its speed by pulling either the D+ or D- line high to 3.3 volts..
[Android Head-Units] aplusmiami:
See attached
[Android Head-Units] aplusmiami:
There are no Android USB devices showing... But here is the screen shot.
[Android Head-Units] aplusmiami:
Another thought:

I know in other Kenwood units there is a service screen to load a custom splash screen and do a factory reset. Not sure how to get there in this unit.
[Android Head-Units] donaldta:
The screenshot you attached doesn't appear as if you opened up any of the paths. There has to be a USB device of some sort connected to your PC's internal hub when you connect the DNN, otherwise those "Linux File-CD Gadget USB Device" wouldn't have appeared. My Device Manager looks like that too if I don't bother to click the paths to open them. Compare the screenshots below.
[Android Head-Units] aplusmiami:
Sorry there you go...
[Android Head-Units] aplusmiami:
To get into the opening Customize Screen:

Vol Down / Power - Reset (Red Triangle)

See this post:

http://xdaforums.com/showthread.php?t=2355155

Made no difference only options there are to change the graphic
[Android Head-Units] donaldta:
Your picture has a better vantage point to reveal the connector you used for the connection. However, may I suggest the following picture to identify the pins you used and the connector's orientation the on the motherboard. That is if you can verify the diagram with your actual connection.

Well, the good news is that you were the first one to determine the location of the USB Peripheral Port on the motherboard necessary for Android Debug Bridge (ADB) and Mass Storage. The bad news is that it does not seem that ADB is enabled for this connection.