Discussion:
[OpenOCD-devel] CMSIS-DAP adapter and connect_assert_srst
Tomas Vanek
2017-04-18 19:09:20 UTC
Permalink
Paul (or anybody else who can test Keil ULINK-ME with CMSIS-DAP),
Hello Tomas,
On Sun, Apr 9, 2017 at 12:06 PM, Tomas Vanek
No, this is OpenOCD issue. I had to change firmware in my
"experimental" cmsis-dap adapter and voila: I replicated your
problem.
If you can recompile OpenOCD from git source, please try
http://openocd.zylin.com/4100
It solves connecting under reset on cmsis-dap (unfortunately on
expense of breaking a workaround for an Keil Ulink adaptor).
Tomas
I compiled the patch from source and tested it. Connect under reset
now works. Many thanks!
Regards,
Leonardo
Leonardo confirmed that workaround in cmsis_dap.c breaks
connect_assert_srst.

IMHO most of cmsis-dap implementations deasserts nSRST signal when
cmsis_dap_cmd_DAP_Connect()
or cmsis_dap_cmd_DAP_Disconnect() is issued because generic firmware
initializes/deinitializes
GPIO lines in connect/reconnect.

The workaround was first introduced in Paul's http://openocd.zylin.com/2356
Comment reads:
/* When we are reconnecting, DAP_Connect needs to be rerun, at
* least on Keil ULINK-ME */

Can you please re-test if this workaround is still needed with up-to
date cmsis-dap firmware?
In other words if the adapter works with applied
http://openocd.zylin.com/4100
we can drop the workaround safely.

Otherwise we should re-issue cmsis_dap_cmd_DAP_Connect() only if no
reset is asserted.

Tom
Paul Fertser
2017-04-19 09:40:20 UTC
Permalink
Hey,
Post by Tomas Vanek
Paul (or anybody else who can test Keil ULINK-ME with CMSIS-DAP),
I do not have access to it this week, but probably will have next
week.
Post by Tomas Vanek
The workaround was first introduced in Paul's [3]http://openocd.zylin.com/2356
/* When we are reconnecting, DAP_Connect needs to be rerun, at
  * least on Keil ULINK-ME */
Can you please re-test if this workaround is still needed with up-to date
cmsis-dap firmware?
I think by reconnecting I meant the case where you were debugging
nicely, then SWD communication got disrupted (interference or loose
contact etc) and then openocd needs to continue the operation. Can you
please test your solution still works for this case?
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:***@gmail.com
Tomas Vanek
2017-04-19 10:32:36 UTC
Permalink
Post by Paul Fertser
Post by Tomas Vanek
The workaround was first introduced in Paul's [3]http://openocd.zylin.com/2356
/* When we are reconnecting, DAP_Connect needs to be rerun, at
* least on Keil ULINK-ME */
Can you please re-test if this workaround is still needed with up-to date
cmsis-dap firmware?
I think by reconnecting I meant the case where you were debugging
nicely, then SWD communication got disrupted (interference or loose
contact etc) and then openocd needs to continue the operation. Can you
please test your solution still works for this case?
I understand that some kind of initialization can help in this point
mainly in case of adapter firmware problems.
All three types of CMSIS-DAP adapters I have (EDBG, Kitprog and
an experimental Kinetis board with open source CMSIS-DAP firmware)
do not need a connect cmd before sending JTAG_to_SWD sequence.
SWD reconnect works on current OpenOCD with #4100 applied
on EDBG and open source fw (not yet tested with Kitprog).

On the other hand we can extend reconnect capability to reconnect USB
(like it works in st-link driver) and in this case all initialization
should be resent.

Tom

Loading...