USB is "Unknown Device" after flash failed [Hudl RK3188 RKBatchTool]

[Andrew I]

I have a "Tesco Hudl 1" tablet (Rockchip RK3188). I tried (yesterday) to flash a ROM to it (using RKBatchTool). Now Win 7 Device Manager lists it as "Unknown Device", so I can't connect via USB, (nor re-install the Windows drivers to enable this)...

It has Stock ROM v1.3.1 (ie. build JDQ39.20140424.153851). I was trying to flash ROM: "Rooted + ClockworkMod Recovery Stock v1.3.1" (from: www.modaco.com/topic/372551-stock-hudl-rom-for-windows-rktools17-latest-available-rom-v131-build-jdq3920140424153851 -- see post#1: sirius-c 25May14).

I followed the instructions there exactly, namely:
1. Developer Options . USB debugging . enable
2. Connected USB: device showed up as "Hudl" (in both Device Manager and Windows Explorer).
3. AdbDriverInstaller.exe: device installed successfully (Device Manager: "Rockusb Device").
4. RKBatchTool.exe: green square (bottom left) confirmed Hudl connected.

But then the actual flash failed with error:
<Layer 5-1> Prepare IDB Fail
**********Restore Done Success<0> Fail<1> Time<118701>ms**********
I tried again and got error:
<Layer 5-1> Test Device Fail
**********Restore Done Success<0> Fail<1> Time<64350>ms**********

Now, on connecting USB, the Hudl fails to appear in Windows Explorer, and appears in Device Manager as: Universal Serial Bus contollers . Unknown Device:
- I am running Win7 Ult. x64 with Faronics Deep Freeze - which means all changes (eg. driver installs) are discarded on reboot, ie. Windows starts clean on every boot.
- I can't get the Windows USB drivers to install successfully now (because "Unknown Device").
- The Hudl still boots, same as before I attempted flash, (although the first couple of times had video problem: fuzzy horizontal lines).

I have checked/tried:
- unplug/reconnect USB repeatedly, and using different USB ports;
- also with Hudl in safe mode.
The Android System Recovery (ASR) menu is still accessible, but I haven't tried a full Factory Reset as yet: I was rather hoping my /data partition might survive when flashing the new ROM.

How likely would Factory Reset resolve the USB problem? Any other suggestions before I try it? eg. is there another way to install the right Windows drivers?
- I have already tried Snoop05: ADB, Fastboot and Drivers (v1.4.2) at: http://forum.xda-developers.com/show....php?t=2588979

Also, if/when USB works again, should I try flashing the exact same ROM again? (have many succeeded with it?) Or use the second ROM in sirius-c's post (ie. rooted but not CWM)? Or is there any other ROM you would recommend? Use a different flash procedure?
Any help much appreciated! thanks, Andrew.

[neomode]

Hello,

Try it with this Method, cause you need the Rockchip Drivers.

http://chinagadgetsreviews.blogspot.de/2014/06/how-to-easily-install-rockchip-rockusb.html?m=1

[Andrew I]

... I followed the instructions there exactly, namely: ...

CORRECTION -- I followed the instructions there exactly, namely:
1. Developer Options . USB debugging . enable
2. Connected USB: device showed up as "Hudl" (in both Device Manager and Windows Explorer).
3. AdbDriverInstaller.exe: device installed successfully ... Device Manager showed: Android Device . Android ADB Interface
4. Windows cmd: adb reboot bootloader ... Windows failed to find driver automatically.
5. Device Manager: updated driver (...\rktools17\RockusbDriver\x64\win7); ... showed it as: "Rockusb Device".
6. RKBatchTool.exe: green square (bottom left) confirmed Hudl connected.

Hello, Try it with this Method, cause you need the Rockchip Drivers. http://chinagadgetsreviews.blogspot....ckusb.html?m=1

neomode: Thanks for your reply. The RK_DriverAssitant you suggest is for my step 5 above, but I'm stuck at step 2/3.
There were also device drivers {usbport, usbhub}.sys, but only for Win 8.1 (not Win 7). Despite this, I did try them, but ... (no surprise) these kill my USB completely, (even my USB mouse).

[CaptainMidnight]

Not sure what's gone wrong there, many people have used that Rom / process successfully.

It's very hard to kill a hudlv1, the factory reset 'should' restore your unit to working order, probably usb is failing as usb debugging and developer modes will have reverted to disabled. I've only heard of people having issues using usb3 ports and leaving the boot firmware (top option) ticked.

[Andrew I]

many people have used that Rom / process successfully

CaptainMidnight, many thanks for replying - that's v.helpful to know.
I'm currently thinking it may(?) be a faulty USB cable...

I see that many Hudl owners have reported USB problems (although mainly with charging). Since the flashing failed, I have tested connecting it maybe 20 times, (always after a clean Windows boot). Twice it did show up correctly (under Other Devices): once as "Hudl" and once as "Android". But only briefly: the slightest hint of cable movement was enough to destroy the connection, (before I could progress past step 2).

So I closely examined the micro-USB port (with torch + magnifying glass). It looks fine, but the cable looks like it has been bent where it enters the micro-usb connector. Tesco help says "You should not be able to move the micro-USB connection in any direction when it is plugged into the Hudl" (http://ttselectrical.custhelp.com/ap...tail/a_id/3558) - in mine there is some movement.

So, I have ordered a new cable, with gold contacts (ie. the best I could find: www.****.co.uk/itm/271783512999). I will report back how I get on with it.

It's very hard to kill a hudlv1, the factory reset 'should' restore your unit to working order, probably usb is failing as usb debugging and developer modes will have reverted to disabled

I'm now thinking the (failed) flashing attempt didn't actually get very far:
- the initial video problems have gone, and the Hudl is working fine (aside from these USB problems; even though I have NOT done factory reset);
- the developer options menu is still there, and USB debugging is still enabled;
- RKBatchTool's console log did not even begin to show any "progress percentage";
- perhaps (even probably?) the dodgy USB connection prevented it from writing much (if anything at all?).

I've only heard of people having issues using usb3 ports and leaving the boot firmware (top option) ticked.

I'm using usb 2, so that should be fine.
What is the tick option for boot firmware? (I can't see it on screenshots: www.google.co.uk/search?q=rkbatchtool&tbm=isch)

[CaptainMidnight]

http://i.imgur.com/1BZAbf3.png

This is what I was talking about above - rule of thumb don't tick the top item i.e. don't flash the loader - everyrhing else just not the loader.

It does sound that you probably have a dodgy usb cable/connection.

[Andrew I]

http://i.imgur.com/1BZAbf3.png This is what I was talking about above - rule of thumb don't tick the top item i.e. don't flash the loader - everyrhing else just not the loader

Thanks for your reply. The tick list (in your screenshot) is not available from RkBatchTool, so I have done a lot of further research, as well as plenty more testing - now with the new cable: Basically, I get windows error: "This device cannot start. (Code 10)". Here are the details:

NEW CABLE
- At the Hudl end (if powered on) I get notifications: USB is connected and debugging is enabled.
- But at the Windows end, Device Manager shows: EITHER "Unknown Device" OR (with luck) something useful under Other Devices (ie. Hudl, Android, or HUDL HT7S3).
In that case, I run AdbDriverInstaller and (with luck) I get Android Device . Android ADB Interface:
- But this always shows a problem, as its properties explain: "This device cannot start. (Code 10)".
- Accordingly running ADB (in cmd window) fails with: "error: device offline".
I suppose it's just possible that this new cable is not suitable (despite its vendor's claims) - I could ask Tesco for a replacement cable, but I think that's clutching at straws. Much more likely my bootloader has been messed up just enough to disable USB:
- before my (original, failed) flash attempt, I was sometimes getting the Hudl to show up in Windows Explorer.
- but since then, this has never happened.

OPTIONS?
My options seem to be:
a. give up: live with hudl as-is -- but this would be rather limiting.
b. factory reset -- but how likely would this even fix the problem? (ie. any similar experience you know of?)
c. flash (replace) bootloader (?) from storage (xxx.zip?) -- see below
d. try linux rkflashtool -- but I'm not v. familiar with linux, and currently I only have the "linpus lite" distro (ie. yum [fedora]; old acer netbook).
In theory, I like option c. best: because it doesn't use USB, and is only flashing <1MB (rather than 1GB). But I can't find a suitable zip, or anyone who has done it before.
Can you advise on these various options?

RKBATCHTOOL = RISKY?
Hudl USB cables are (seemingly) often unreliable. So flashing the bootloader with them seems correspondingly risky: fortunately my Hudl did not brick, but I think(?) that's a real possibility with sirius-c's instructions: He says use RkBatchTool, ie. no mention of the (alternative) RkAndroidTool.
See: www.cnx-software.com/2013/11/19/how-to-flash-rockchip-rk3066-rk3188-firmware-in-linux
> "Rockchip provides 2 tools to update the flash:
> - RkBatchTool – Used to upgrade firmware with a single file
> - RkAndroidTool – Used to flash the NAND flash with image corresponding to particular partition, e.g. system.img. kernel.img, boot.img. recovery.img. etc… "
ie. RkBatchTool does NOT give any option to 'untick' flashing the bootloader.
Any thoughts?

[CaptainMidnight]

Have a look on Modaco under hudl1 forum - I'm sure you'll find a v1.3.1 hudl rom that is flashed with the tool that is the same as the picture I refferenced - if not found shout out and I sort something out

At work now. But can help later.

[Andrew I]

Thanks for your reply. RkAndroidTool is like your screenshot. But since the failed RkBatchTool has messed things somewhat, the problem is earlier, in step 2: getting USB to work at all.

When you have a chance, I would much appreciate if you can shed any light on the questions in my post #7.

If/when USB finally works again, I will certainly use RkAndroidTool when flashing any ROM via USB, (ie. not RkBatchTool - which seems pointlessly risky).

Or, hopefully I might even get Linux RkFlashTool working someday: This article www.pentestpartners.com/blog/how-to-hack-the-hudl-we-give-rockchip-a-good-seeing-to/ says it's better: "...Rockchip Batch Tool ... drivers are quite dodgy and don’t like 64 bit Windows. Fortunately ... you can get ... for Linux, rkflashtool"

[CaptainMidnight]

Firstly please restate 'exactly' what current state your hudl1 is at?

You say it's of limited use as it is, please explain.

I'll be honest without a full current explanation of what it can/can't do and if you can/can't connect to it from/in what mode it's hard to give you a clear action plan.

Things might bave moved on since last time hence I'm just checking up first.

[Andrew I]

Thanks for your reply & sorry for the delay in mine.

I have been using the Hudl without any problems, EXCEPT: I can't connect it to my Win 7 PC (via USB). Or, (more precisely), the only effect this has is to charge the Hudl - ie. Windows can't even see it as a media device (MTP), so ADB doesn't even get close to working.

Typically the device, when it’s not completely "unknown" (in Windows Device Manager), states: "This device cannot start. (Code 10)". This happens whether the Hudl is powered on or off, or even if I have launched ASR (Android system recovery, using Hudl's power and volume buttons) and selected "apply update from ADB".

By 'limited use', I mean I cannot root it or use any developer tools. I am quite interested in both of these, because I am trying to better understand and control the way that Android works (under the covers), and possibly do some App development work.

[raxy]

maybe you should return to a more controlled firmware
use Linux to do that,
Linux is mandatory for all rebuild of kernel or android from sources and has decent Flashing tools,
but for kitchen tools to operate at binary level, I am not sure...

[CaptainMidnight]

I would suggest your issue is either a faulty usb cable or more likely incorrect drivers and it also could be a combination of the two.

Do you have a smart phone to try and connect to your windows computer / or a friends so that you know with the right drivers the cable should work? From there you can return to the possible driver issues with your hudl.

Worth double checking usb debugging is still enabled and potentially worth uninstalling deepfreeze as it may be conflicting - it's a long shot but worth consideration.

Also try and use a usb2 port and any command line stuff with administrator privileges.

[Andrew I]

Thanks both for your replies. I am snowed under now, hence my own slow replies.

- USB debugging is still enabled. I am using usb2 port, and I have consistently elevated the command line (ie. run it as admin).
- Incorrect drivers? No, the problem arises earlier in the procedure - I have the right drivers available to install, if given the chance to use them (they have worked before).
- I very much doubt DeepFreeze is the culprit, but trying another PC will check that.

What next:
- I will try with another PC - that's a very good idea.
- I have tried 2 cables (one Tesco, other from ****) but I will ask Tesco for another cable.
- Eventually I will try from Linux - I realise it makes more sense really, with Android being Linux based.

I will keep the thread posted, but it may be a while now. Thanks again.

[CaptainMidnight]

Only other remote possibility is a dodgy USB port on your hudl - it has been known before but is not likely to be the issue. Trying another PC that hasn't had you hudl connected is the best next step. I'd put money on a driver issue / windows driver confusion by the computer.

Remember seeing somewhere think it was back on modaco of being able to force the correct hudl USB discovery by editing the USB config driver file with the correct hardware ID's (or words to that effect). I'll try and dig it out.

Another possibility (dependent on your local resources) would be to setup a 'virgin' windows install on a different drive i.e even an external HD so you can boot from that to carry out some tests. This negates deepfreeze and your current setup etc - not saying it's wrong just it's possibly got 'confused'. I would have suggested trying this in a virgin windows VM but haven't had great experience getting VM's to use USB successfully enough when the VM host has issues - but others swear by it.

Anyway some more food for thought, just more idea's really when you have more time.

By the way, hudl source is available from Tesco as you're probably aware, but others have said it's missing chunks of code like hardware drivers etc.