Hi All,
Is there some BIOS support needed for debugging over USB. I have vista and Win-7 target for debugging. What are other things that I will need ?? I have the PLX USB 2 Debug cable.
Thanks,
– Ajitabh.
Hi All,
Is there some BIOS support needed for debugging over USB. I have vista and Win-7 target for debugging. What are other things that I will need ?? I have the PLX USB 2 Debug cable.
Thanks,
– Ajitabh.
Well, there are requirements, but…
windbg docs:
The target computer must have a USB 2.0 controller that is compatible with the EHCI specification, and which supports kernel debugging. Not all EHCI-compatible controllers have this support, and there is no programmatic method to determine whether a given computer does have this support.
Also, you have to connect to the ‘usb debug port,’ which I believe means port 0. How one identifies port 0, I have no idea, and I’ve heard that a common problem is that port 0 is sometimes inside the machine and thus basically inaccessible.
An additional thing to consider is that establishing a kd usb connection means that you can’t use the rest of the ports on the controller.
While I’m sure that someone here has gotten usb to work successfully, I can’t recall anyone reporting that they have, so I really don’t know what to tell you to do other than try, assuming that you can’t use either serial or 1394.
If you can use either of those, I would strongly suggest that you do so, but I can’t imagine that either of those are options, given that you’ve actually gone through the trouble and gotten the cable, no small feat in and of itself.
Good luck,
mm
You are correct. I do not have 1394 or serial on the machine. So I am not sure how can I hook up debugger without the last option which is USB.
Is there a way to make the USB to serial work on the target machine so that it can connect to machine running the Windbg??
Last time I tried that I was not successful.
Any other Ideas??
– Ajitabh.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@evitechnology.com
Sent: Tuesday, August 11, 2009 6:18 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Debugging Over USB
Well, there are requirements, but…
windbg docs:
The target computer must have a USB 2.0 controller that is compatible with the EHCI specification, and which supports kernel debugging. Not all EHCI-compatible controllers have this support, and there is no programmatic method to determine whether a given computer does have this support.
Also, you have to connect to the ‘usb debug port,’ which I believe means port 0. How one identifies port 0, I have no idea, and I’ve heard that a common problem is that port 0 is sometimes inside the machine and thus basically inaccessible.
An additional thing to consider is that establishing a kd usb connection means that you can’t use the rest of the ports on the controller.
While I’m sure that someone here has gotten usb to work successfully, I can’t recall anyone reporting that they have, so I really don’t know what to tell you to do other than try, assuming that you can’t use either serial or 1394.
If you can use either of those, I would strongly suggest that you do so, but I can’t imagine that either of those are options, given that you’ve actually gone through the trouble and gotten the cable, no small feat in and of itself.
Good luck,
mm
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Unfortunately not. Windbg requires a legit 1650 UART on the target, and I don’t see how what you’re proposing would not still require the same things of usb on the target.
What kind of machine is the target? Does it have ANY kind of expansion bus - PCI, PCMCIA, CardBus, et. c.? How about internal headers (1394 or serial) that just haven’t been populated?
mm
More information would help. Why not just install a 1394a PCI card? PCIe?
Yes, if you have a Dell system targeted at the enterprise, USB will work.
You just have to find the correct connector to use. Keep trying them all.
USB to serial adapters only work on the host system. Look at the hardware
via device manager using the “Devices by Connection” option under view. See
if Port zero on the lowest numbered EHCI controller is available. You can
use a USB stick to find the correct port by trying them all and refreshing.
“Ajitabh Saxena” wrote in message
news:xxxxx@ntdev…
You are correct. I do not have 1394 or serial on the machine. So I am not
sure how can I hook up debugger without the last option which is USB.
Is there a way to make the USB to serial work on the target machine so that
it can connect to machine running the Windbg??
Last time I tried that I was not successful.
Any other Ideas??
– Ajitabh.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@evitechnology.com
Sent: Tuesday, August 11, 2009 6:18 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Debugging Over USB
Well, there are requirements, but…
windbg docs:
The target computer must have a USB 2.0 controller that is compatible with
the EHCI specification, and which supports kernel debugging. Not all
EHCI-compatible controllers have this support, and there is no programmatic
method to determine whether a given computer does have this support.
Also, you have to connect to the ‘usb debug port,’ which I believe means
port 0. How one identifies port 0, I have no idea, and I’ve heard that a
common problem is that port 0 is sometimes inside the machine and thus
basically inaccessible.
An additional thing to consider is that establishing a kd usb connection
means that you can’t use the rest of the ports on the controller.
While I’m sure that someone here has gotten usb to work successfully, I
can’t recall anyone reporting that they have, so I really don’t know what to
tell you to do other than try, assuming that you can’t use either serial or
1394.
If you can use either of those, I would strongly suggest that you do so, but
I can’t imagine that either of those are options, given that you’ve actually
gone through the trouble and gotten the cable, no small feat in and of
itself.
Good luck,
mm
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
I debug using USB (real true blue “bcdedit /dbgsettings USB targetname:debug” sort of debugging)
You can only use USB debugging on Vista or Win7. I don’t know about the server OSs because I don’t develop for them.
You must buy a special USB debugging adapter. Net20DC USB 2.0 Debug Cable from PLX Technology
http://www.semiconductorstore.com/cart/pc/viewPrd.asp?idproduct=12083
You must have a high speed USB 2.0 controller that supports debugging. I’ve never seen a list of controllers that do support debugging, but every Intel chipset I’ve tried in the last 2 years has worked.
Your BIOS must initialize the USB 2.0 controller. Suprisingly I’ve seen 2 BIOSs that did not support this, but a call to the vendor produced new BIOS code that fixed the problem.
You must be able to find USB port 0 on your computer. I’d suggest using USBVIEW.EXE that comes with the Windows Driver Kit. You will have to build it for yourself. Note that if there’s more than one USB 2.0 controller, you’ll have to figure out which of the controllers Windows decided is really port 0. If port 0 doesn’t come to an external port you’re hosed.
Open cmd.exe with admin privlidges and run
> bcdedit /dbgsettings usb targetname:debug
> bcdedit /debug yes
Run wndbg and select kernel debugging/usb. Set the name to “debug”
Debug as you would with serial or fire wire.
I just reread what was posted earlier and have one correction to someone’s comment.
“An additional thing to consider is that establishing a kd usb connection means
that you can’t use the rest of the ports on the controller.”
The only port that becomes unusable is port 0. All other ports on the controller continue to be fully usable.
Here’s some other hints:
I have found port 0 a couple of times buy turning on debugging and moving a thumb drive from port to port until I found the port that it wouldn’t work on.
I have one system where port 0 was on the express card slot. I have a firewire express card that also brings the USB port out so i could debug using that. If you’re wondering why I didn’t just use firewire, it’s because for whatever reason, I’ve never gotten
USB isn’t quite as fast as fire wire. I’d say it’s about 80% though.
Once you get everything ready and reboot, you can check the registry to see if windows thinks debugging is running. If HKLM/System/CurrentControlSet/Services/PCI/Debug exists, then windows found a USB controller that it supports.
I have had the debug cable hang up a few times. You must unplug both ends to get it to clear and reset. The same is true if you want to debug a different computer with a different targetname.
If you boot the target computer with the debug cable attached it sometimes boots very slowly.
If you boot the target computer with the debug cable attached but without wndbg loaded and running windows might hang until you start wndbg.
If you boot the target computer without the debug cable attached, then attach it later you will have to hit the breakpoint button (I forget the function key) to get the connection to establish. It can take 20+ seconds for windows to break the first time so don’t get flustered. Just wiggle the mouse on the target computer and if it doesn’t move, then wndbg is doing its thing. If the mouse continues to wiggle then something isn’t right.
The USB debugging is real true blue USB 2.0 speeds. You can go through hubs but your cables had better be good. And if the target computer has any marginal connectors or routing paths it might not work at all. The fire wire express card that I mentioned earlier works, but I always have to be careful beause if I wiggle it much I loose the connection.
Also search the windbg documents for the command: “loadoptions
/busparams=Bus.Device.Function”. It is an option for the boot configuration
setup.
wrote in message news:xxxxx@ntdev…
>I debug using USB (real true blue “bcdedit /dbgsettings USB
>targetname:debug” sort of debugging)
>
> You can only use USB debugging on Vista or Win7. I don’t know about the
> server OSs because I don’t develop for them.
>
> You must buy a special USB debugging adapter. Net20DC USB 2.0 Debug Cable
> from PLX Technology
>
> http://www.semiconductorstore.com/cart/pc/viewPrd.asp?idproduct=12083
>
> You must have a high speed USB 2.0 controller that supports debugging.
> I’ve never seen a list of controllers that do support debugging, but every
> Intel chipset I’ve tried in the last 2 years has worked.
>
> Your BIOS must initialize the USB 2.0 controller. Suprisingly I’ve seen 2
> BIOSs that did not support this, but a call to the vendor produced new
> BIOS code that fixed the problem.
>
> You must be able to find USB port 0 on your computer. I’d suggest using
> USBVIEW.EXE that comes with the Windows Driver Kit. You will have to
> build it for yourself. Note that if there’s more than one USB 2.0
> controller, you’ll have to figure out which of the controllers Windows
> decided is really port 0. If port 0 doesn’t come to an external port
> you’re hosed.
>
> Open cmd.exe with admin privlidges and run
>>> bcdedit /dbgsettings usb targetname:debug
>>> bcdedit /debug yes
>
> Run wndbg and select kernel debugging/usb. Set the name to “debug”
>
> Debug as you would with serial or fire wire.
>
I asked a little while ago to have that added to the docs, but I don’t think it has ever made it there.
http://www.osronline.com/ShowThread.cfm?link=152062
http://www.eggheadcafe.com/software/aspnet/31073603/1394-debugging-issues-ta.aspx
Good luck,
mm
> If you boot the target computer with the debug cable attached it sometimes boots very slowly.
Same occurs with serial port debugging on some motherboards, especially with pre-Vista OSes.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com