On Jun 17, 2009, at 4:51 AM, Audrius Urmanavičius wrote:
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 coupleof error recovery situations where it could get confusing for a user(probably me). Possibly this has been discussed before but a quick lookat 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?
We have a number of non-USB based interfaces that do not support hot- plug. All of the USB-based interfaces are required to support hot- plug since it is a requirement of USB. The point is that we can't easily generalize hot-plugging to all interfaces. We'd need to declare which interfaces support it.
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.
We don't really handle USB hot-plug either. In both cases, we can't guarantee that the target is the same unless we reexamine the bus and reset state. That's not a bad idea, but it also isn't necessarily what someone would expect. We shouldn't rely on the assumption that it will be the same target. The first time it isn't, things will explode. For the moment, both hot-replug cases (JTAG and USB) should cause OpenOCD to terminate.
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.
If that's what the user wants. I personally would never do that. Hence why I'm hesitant to introduce such behavior directly in OpenOCD.
These aren't big problems for me now, but I would prefer to have openocdrunning 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
-- 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
