Rick Altherr 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.
I guess what I am saying is that if the devices is not there, just
branch back to main() and start again after a bit of delay (could be an
option). Or the user could do this on their own in a script.
>
>> 2. With openocd correctly running and connected, if the jtag is
I meant to say "usb is disconnected". But if jtag is disconnect (with
olimex ftdi adapter) it spits out continuous "Warn : Invalid ACK in
SWJDP transaction" put when I plug the jtag back to the board (currently
using Olimex stm32-h103) it recovers and I can continue
stepping/debugging again.
>> 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.
Right now it doesn't terminated if USB is disconnects but keeps spitting
out "usb bulk write failed" messages (for my setup) and won't recover.
There could be an option to also branch back to main ("reboot" openocd)
if more than X of these errors occur in a row. ...Just an idea :) I
guess you have to assume that you have re-plugged to the same or similar
target since the openocd cmd line pretty much specifies the target (in
my case always stm32.cfg with 3 different boards that all work with that
target file).
Once I put openocd to real use, the environment will be static (same
board, same jtag adapter etc).
>
>> 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
