I'm trying to understand what happens in one prototype board I have, because Flash programming through Atmel Studio is now very very slow.

It seems the Flash programming speed dramatically decreases when I enable WDT (watchdog timer) in my program. It's very strange to me, because I thought the core is maintained in a reset status during Flash programming, so with WDT disabled. How is it possible that the firmware that is running changes the Flash programming speed?

I started making some tests in order to understand more deeply what happens, so I observed the RESET line on the SWD connector. I noticed it isn't controlled during Flash programming, it seems it stays high for all the time. Is it correct? Hot the MCU is put in reset during Flash programming? Maybe is there a SWD instruction that resets the MCU core, so avoiding the use of the RESET line?

What could be the reason of so slow Flash programming process?

Quite the opposite.
The MCU is running the code which is programming the flash.

I see. Where is this code? I think J-Link download a small "applet" in RAM and run it from RAM. Correct?

In that case, what is the configuration of clocks? After POR, SAMD20 core clock is 1MHz (from internal 8MHz oscillator, divided by 8). The application code could change the clocks at runtime.

Suppose my application code starts changing the MCU and peripherals clocks. During application execution I start a programming session through Atmel Studio. J-Link download the "applet" code to the RAM memory and run it. Does J-Link issue a reset command, so the MCU (and peripherals and registers) starts from a well-known state (for example, MCU core clock is 1MHz)? Or the programming happens with the current configuration that was made by the application?

I thought the programmer issues a reset (from the RESET line or a SWD command) and starts programming before starting the user application (that could change chip configurations).

Indeed I noticed that when the application is not running (because I stop the external clock that is used as the source of MCU core clock, or after a chip reset) the programming process is always fast/normal. When my application is runnning with WDT enabled, the programming is very slow.

I can't erase the entire chip, because there's a bootloader.

If the WDT is running, the RAMCode needs to feed the watchdog.
However, this should not slow down the flash programming process significantly.

Hmm..., is this "RAMCode" the "applet" that is downloaded from J-Link to program the Flash memory?
In SAMD20 there is a complex syncronization mechanism. WDT is clocked from 1kHz clock and core clock runs usually at MHz. If I try to reset the WDT too often, the bus stalls for some ms!! Because the WDT register that must be written to feed the watchdog is Write-Syncronized. The big difference between the clocks leads to a long syncronization time.
The solution I found in my application is to reset the WDT every about 100ms (the WDT is configured to fire only after some seconds).
Maybe your "applet"/"RAMCode" is resetting the WDT too often and the overall speed is affected by the bus stall.

Are you sure nothing else has been changed, like MCU clock speed, flash controller speed / divider, flash wait states?

Sure, I change many things at startup, clocks configuration too. However I don't touch Flash controller speed/divider. Flash wait states are configured to 1.
The MCU core runs at 48MHz (GCLK Controller 0), coming from DFLL48M. The source of DFLL48M is an external 32.768kHz clock coming from a pin.

If you think it is useful, I can post my initialization code.

This explains the observed behavior.
Currently, the RAMCode does not analyze the WDT Configuration but just checks if it is active and feeds it if it is.

I will bring this issue up on the next team meeting, if we can improve this behavior.

Ok, thank you. Do you know what is the policy of feeding the watchdog?

It is the callers (=IDE or Debugger) responsibility to execute a reset before flash programming.
The RAMCode itself does not issue a reset for various reasons, among others since it also handles the flash programming of the flash breakpoint feature and resetting before flash programming does not work for each setup and target device.

The RAMCode does have a prepare() and a restore() function, which can be used to change the configuration of the target device before flash programming and restores the original configuration afterwards.
As for as I know, unfortunately, information about what is done in the prepare() and a restore() functions for a specific RAMCode (for a specific device, e.g the SAMD20) is not published by SEGGER and therefore I cannot elaborate on this topic here.

Do you know how to configure Atmel Studio IDE to reset the device before flash programming?