On Tue, Jun 16, 2009 at 11:04 PM, Rick Altherr <kc8...@kc8apf.net> wrote:
> > On Jun 16, 2009, at 11:06 AM, Gene Smith wrote: > > At this time openocd is working quite well for me with 3 different jtag >> adapters: rlink, jlink and olimex/ftdi. However, I have noticed a couple >> of error recovery situations where it could get confusing for a user >> (probably me). Possibly this has been discussed before but a quick look >> at the maillist subjects didn't reveal anything. >> >> 1. If the user is not connected to the adapter via usb when openocd is >> started you see: >> >> Error: unable to open ftdi device: device not found >> >> and openocd terminates. >> >> I guess you could put ./openocd in a script to retry with some delay. >> But maybe openocd could delay and retry on its own if "device not found" >> at start up? >> >> > This is potentially poorly worded, but correct, behavior. You asked > OpenOCD to start using a device that isn't attached to the machine. While > USB does support hot-plugging, not all of our supported interfaces do. > That's strange if there are actual USB JTAG interfaces that does not support hot-plug (i.e. connecting of USB cable while PC is up and running). Do they have to be connected to USB right away when computer is powered on? > > > 2. With openocd correctly running and connected, if the jtag is >> disconnected I see a continuous stream of "usb bulk write failed" >> messages. Reconnecting the cable does not fix the situation and the >> errors keep coming. The only way to recover is to kill openocd and >> restart it. >> >> > This is a known problem. We don't support disconnect/reconnect on USB. We > could. In fact, Dick had patches for FTDI-based devices to do so. The > danger here is failure cases where an instance of OpenOCD was running with a > dongle attached. That dongle was disconnected, attached to a different > target board, and reconnected. To OpenOCD, we'd assume it was a reconnect > to the same target. We'd need some way to force a reexamination of the JTAG > chain on reconnect to determine if it's the same target or not. This all > gets very messy. So, for now, we should probably terminate if the interface > is disconnected. > The possible target change is not sufficient reason to not implement hot (re-)plug; the users of OpenOCD are usually dealing with one piece of HW at a time and/or are smart enough not to swap boards whild openocd is running. In fact, i is possible to swap the target while USB is still attached (hot JTAG re-plug - while not very elegant but doable, and, if taken precautions, does not damage the adapter/board), this case is not handled by openocd anyway. A termination upon interface disconnection would indeed be much more useful instead of dumping error messages to console/log. A simple shell script could then attempt to restart openocd. > > > These aren't big problems for me now, but I would prefer to have openocd >> running as a background daemon/service, out of sight/out of mind, that >> just recovers on its own when I do the wrong thing. >> >> Have these scenarios been considered? Maybe I am missing something >> obvious? >> >> Thanks, >> -gene >> >> >> _______________________________________________ >> Openocd-development mailing list >> Openocd-development@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/openocd-development >> > > > -- > Rick Altherr > kc8...@kc8apf.net > > "He said he hadn't had a byte in three days. I had a short, so I split it > with him." > -- Unsigned > > > _______________________________________________ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > >
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
