On Tue, Jan 06, 2009 at 09:35:09PM -0000, Spencer Oliver wrote: > Freddie, > > > > Open On-Chip Debugger 1.0 (2009-01-06-18:35) svn:unknown > > > > > > > > > BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS > > > > > > > > > $URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $ > > > Error: No device found on bus. > > > > running in debug mode gives nothing more - only the init > > functions are executed, the error is produced by rlink_init() > > > > it actually doesn't matter if the Primer is connected or not, > > powered or not - the msg is always the same. The Primer and > > it's RLINK work under Ride7, so I guess my problem is > > situated in software... > >
The rlink_init function is pretty simple in this regard. It uses libusb to scan the bus for a device with matching vendor and product IDs and attempts to open it. If no suitable device can be found, it reports the error that you see. As far as libusb can tell, the device is not plugged in. We could replace the USB device scan/open code with that from jlink.c. The desired result is the same. The actual result (can't run it with the Jungo driver installed) would probably also be the same, however. > The issue is that the rlink uses a slightly unique driver (forget the name) > that the libusb filter driver cannot see. > you have to remove the standard rlink driver and use the main libusb driver. So that driver being active prevents the interface from even so much as appearing to libusb? Freaky. The rlink support uses libusb, so anything that is needed to use libusb under Windows is needed here. Including things like not having other drivers competing with libusb for the device. > > This is a pain as other interfaces (jlink, ftdi) behave fine with the filter > driver. If there's something I should be doing differently to make that work nicely, I'm interested. I don't know what that would be, though, since the device seems not to even show up in the bus/device list under the problem condition. Perhaps that's something to do with the way the/a filter driver works. I don't have a Windows machine to test on. Only Linux. I surmise that this filter driver thing has something to do with LibUsb-Win32. > To be honest though the best way to access the interface is directly rather > than using the filter driver. Well ok, then. Any drawbacks? > > I have attached the inf for a standard rlink - if this does not match the > primer than use inf-wizard.exe (part of libusb) to generate the correct inf > file. Should something like that be added to OpenOCD? Or is that sort of thing generally regarded as up to users or packagers? If the former, where/how? If the latter, does it at least need to be documented somewhere? > > The downside of all this is that you cannot use RIDE and openocd at the same > time. That would appear to be an unfortunate side effect of RIDE's driver claiming the device in some way. It might be valid to assume that someone who's happily using RIDE probably wouldn't also be using OpenOCD for the same device. _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
