Target is reset twice.

[jcarrano]

Description

This change (b65dc24#diff-00259a9e325566089cd936bcc3e75e50R564) caused targets to be reset twice. This is relevant when one just wants to reset (using, e.g., edbg -t atmel_cm0p)

The first reset:

edbg/edbg.c

Line 564 in b65dc24

dap_reset_target_hw(1);

The second reset:

edbg/edbg.c

Line 680 in b65dc24

dap_reset_target_hw(1);

Why is it relevant

In the RIOT OS test suite we reset the boards at the beginning of each test. The test script waits for a known string to start the test. With the current edbg behaviour the test starts and shortly afterwards the board is reset, causing it to fail. Since this is happening only with atmel boards using edbg, I'd like to avoid having to add a specific kludge to handle it in the test infrastructure if I can avoid it.

Steps to reproduce

Load an program that does something immediately after boot, for example output a string over the UART. In my case I'm running the RIOT OS test suite, and listening on the serial connection.

Reset the board with edbg -t <target type> (in my case atmel_cm0p.)

Expected result

Board is reset once thus the message is sent once.

Actual result

Board is reset twice in a short span thus the message is sent twice.

[ataradov]

It is probably safe to switch to "dap_reset_target_hw(0);" CM4v2 at this point does a reset with extension in the target_select() code anyway.

The next problem would be that target_deselect() does a software reset, which would be followed by the hardware reset. This is done to ensure operation without a reset pin.

I have no problem with the first change, in fact I think the whole reset may be removed from here and moved to individual targets select procedure. I will do that later today after some testing.

But the second one will be remain as is, so if this is still a problem, removing the first reset will not help much.

It is possible that target_deselect() and dap_reset_target_hw(1) happen fast enough that MCU does not have time to run any useful code, of course.

[jcarrano]

@ataradov Thanks for the quick response.

It is possible that target_deselect() and dap_reset_target_hw(1) happen fast enough that MCU does not have time to run any useful code, of course.

Yes, I think that is the case, because I don't experience any issue with commits prior to b65dc24.

[ataradov]

I've moved the initial reset into the target specific code. This should fix your issue.

[jcarrano]

I can confirm that the issue is solved. Thanks for the prompt response!