On Mon, Jul 6, 2009 at 9:18 AM, Gary Carlson<[email protected]> wrote: > Hi Xiaofan, > > The session transcript that you provided below seems to indicate a different > problem then my patch would fix in your case. Was this for the Arch Linux > or all host systems? One of your earlier messages indicated success, so > knowing that helps.
Your patch works for Ubuntu 9.04 (without the patch it works as well but sometimes got initialization error). I have not tested Fedora 10 but I believe it would work. It failed under Arch Linux and OpenSuse 11.1 (without your patches it did not work either. Your patch at lease helped to remove the initialization error). Take note all these 4 Linux distros are installed on the same computer. I also use the same USB port to connect the J-Link. > Judging from your log, you seem to be getting outright write errors out of > the USB port to the dongle. > > I obviously don't have your dongle, target, and computer in front of me or > know your technical background, but here are some starting suggestions of > things I would try to narrow the problem: > > 1) If you have a DSO with a differential probe you may want to look at the > data signals emitted onto the USB link. Are they reasonably clean at the > dongle? > > 2) As part of the previous suggestion, if you write a simple test loop and > emit one test command to the dongle at each startup, do you see signal > transitions at all or does the port seem to be dead during the failures? If > you send one command at a time and everything works normally every time, > what happens if you modify the test loop to send the same command in rapid > succession instead? Does the link then break? I was doing that at home so no DSOs. At work, I have DSOs but probably I would not want to do this type of things at work. > 3) If you have a good USB sniffer, have you done a closer inspection of what > is actually crossing the link? The simple test loop helps here so that you > are not overwhelmed by data. Maybe USBmon under Linux but it is a bit difficult to understand the log. On the other hand, I will try some old versions of OpenOCD. I remember it was working last time. On the other hand, Segger's Linux utility seems to work fine. > 4) Verify that your board is actually being reset during initialization by > monitoring the reset line into the processor using the DSO or reset LED (if > your board has one). Over 20 years of working on multitudes of different > processors and emulators I can't think of all the times that I nearly pulled > out my hair tracing odd problems only to find out that the board was not > reset like it should have been. If your link is working at all, the very > first thing you should see is the board tossed into reset by the dongle if > the first few USB writes are interpreted correctly. > > 5) What version of libusb do you have on your system(s)? If you are using > an older version, you may be running into bugs that have since been > corrected in the USB support library. I think Arch Linux and OpenSuse 11.1 have the latest version of libusb. Actually I normally run the latest version of libusb 0.1 and libusb 1.0 (svn version) under my main Linux distro which is Ubuntu 9.04. > 6) What hardware version of USB does your host system have (USB 1.0 > or USB 2.0)? It is a USB 2.0 high speed port. As I mentioned before, I am using the same computer (An Acer M1641, GeForce 7050 / nForce 620i ICP chipset, Intel Core 2 Duo E4700), same USB port. > Anyway some things to think about. Thanks for the hints. -- Xiaofan http://mcuee.blogspot.com _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
