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:

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.