atmel_cm0p, timing between reset and command (erase/read/flash) problem

[biboc]

If the GPIO use for SWCLK or SWDIO is reconfigured (MUX GPIO) just after boot on the target, edbg does not success to erase/flash/read the target

It is a timing problem

I inverted some commands on edbg.c to not loose time after board reset:

  dbg_open(&debuggers[debugger]);

----------------------------------------
  dap_get_debugger_info();

  print_clock_freq(g_clock);
----------------------------------------
// above and below has been inverted here to show success code
----------------------------------------
  dap_reset_target_hw(1);

  reconnect_debugger();
----------------------------------------
  target->ops->select(&g_target_options);

And it works great I have no time yet to make this short pull request, so I'll will do later if nobody did it before

[ataradov]

The reset was intentionally removed from this place, since it created other problems. This will only work if your target is slow enough and debugger is fast enough anyway.

If you redefine the SWDIO and SWCLK pins, then you must have RESET pin connected and in this case reset extension should keep the part in a reset state and not let it run any code. This is true for Cortex-M0+-based parts.

What MCU are you trying to program?

[biboc]

If you redefine the SWDIO and SWCLK pins, then you must have RESET pin connected and in this case reset extension should keep the part in a reset state and not let it run any code. This is true for Cortex-M0+-based parts.

I have a SAM R30 (Cortex-M0+) and Reset pin is connected but the board does not seem to be in reset state since I can see the board reboot

With my setup (debugger + target), it works What do you suggest?

[ataradov]

What does it print on the output when you run unmodified code?

[biboc]

With unmodified code:

$ edbg -t atmel_cm0p -b -v -e -p -f bin/firmware.bin 
Debugger: ATMEL EDBG CMSIS-DAP ATMLXXXXXXXXXXXXXX 01.1A.00FB (S)
Clock frequency: 16.0 MHz
Error: invalid response while writing the register 0x0d (count = 0, value = 7)

[ataradov]

So you are using EDBG chip. Is this a stock development kit? Can you attach the binary file that causes this problem?

It really looks like reset line is not connected or not controller by the EDBG (I think this happens on a few kits, not sure if R31 is one of them).

In the target_select() function in the target_atmel_cm0p.c add while (1) before reset_with_extension(); and observe the reset pin of the device. Does it toggle at all?

[biboc]

Yes EDBG chip mounted on SAMD11 Explained Pro board. We removed 2 resistors at the back For the binary, I can't provide as it so I'll need to make a simple one that show the problem.

When running edbg command, the board reboots so I assume RESET line is connected?

[ataradov]

Wait, is it R30 or D11? Or are you programming R30 via D11 EDBG? On SAM D11 Xpro reset of the EDBG is connected to the CORTEX DEBUG connector. What resistors have you removed? The board may reboot from the debugger command as well, but if the board reboots while you get that error message, it probably means that is is actually reset by the external signal. And that is very strange that it does not work in this case.

Is there any excessive capacitance on the reset line on the target board by any chance?

[biboc]

I use a D11 Explained Pro board (EDBG) to flash a SAMR30 chip I've removed res R303 and R304 to use EXT SWDCLK and EXT_SWDIO instead of ATSAMD11

On target, there is a 100nF capacitance.

I've tried with a ATMEL-ICE and it is the same On ATMEL-ICE I use connector SWD to 0-10 pin and I use pin named 0 on label for RESET line

What's your feeling?

[ataradov]

100 nF may be a bit much, depending on the pull-up resistor. It would be helpful to see an oscilloscope or a logic analyzer capture of the RESET, SWDIO and SWCLK signals and their relation to each other.

Absent that, you can try to make EDBG it wait a bit longer after the reset is applied. Try changing sleep value from 10 ms to 1000 ms (extreme) in reset_with_extension() in target_atmel_cm0p.c.

You can also manually test that reset extension mode works. If you have a way to tell that application is running (LED blinking or similar), then do this:

1. Power on the board
2. Make sure that application is running
3. Connect SWCLK to ground.
4. Connect RESET to ground.
5. Relese RESET to ground. Items 4 & 5 can be done via reset button if you have one on the board.
6. Target should not be running at this point, even though reset is not asserted. This is a reset extension mode that should make application image irrelevant.
7. Release SWCLK to ground. Target still should be in reset.

If this sequence works, then the only thing I can think of is timing between all those SWD signals. And logic analyzer could shed some light on that.

Also, try to lower SWD clock frequency (add "-c 100" on the command line).

Does this even depend on the application binary already programmed into the device? Does this work on a completely erased device? If it depends on a specific binary, I would really like to see it. It does not have to be a complete project, just remove most of the stuff, as long as it still reproduces the issue.

[mraardvark]

Agree that 100nF is a bit much on reset. I think 10nF or even 4.7nF would be a good value.

[biboc]

@ataradov

100 nF may be a bit much, depending on the pull-up resistor. It would be helpful to see an oscilloscope or a logic analyzer capture of the RESET, SWDIO and SWCLK signals and their relation to each other.

I'll do soon

Absent that, you can try to make EDBG it wait a bit longer after the reset is applied. Try changing sleep value from 10 ms to 1000 ms (extreme) in reset_with_extension() in target_atmel_cm0p.c.

No change

I'll test the method to see if my board goes on reset extension mode

By the way, we have a 100K to do the pull up How much do you recommend? 100K and 100nF is recommended in ATMEL datasheet

Also, try to lower SWD clock frequency (add "-c 100" on the command line).

No change

Does this even depend on the application binary already programmed into the device? Does this work on a completely erased device? If it depends on a specific binary, I would really like to see it. It does not have to be a complete project, just remove most of the stuff, as long as it still reproduces the issue.

If I've got time, I will

[biboc]

SCALE are different

This is a board without SWCLK pin configuration at boot:

This is a board with SWCLK pin configuration at boot:

[ataradov]

I usually do something like 100K/10nF as a first pass and adjust later if there are problems. The datasheet recommendation is strange.

But can you at least confirm that this is only observed if some specific image is programmed into the device? If you program any random file using some other method and then try to program using this tool, does it work? I want to understand if this is some strange behaviour induced by the code, or this is something with the board.

By "SWCLK pin configuration at boot" you mean in the running application? That sounds like a suspect part. How exactly it is configured?

[ataradov]

Ok, nevermind the last part. I re-read the original question.

So it looks like holding the SWCLK pin low actually does not prevent the MCU from running. You can see that debugger can't override the pin, which appears to be driven low by the application. This is interesting . I will experiment with that tomorrow.

[ataradov]

I don't have R30 board, but I tried on L21 board, which uses the same MCU die. I could not reproduce this behaviour. I set SWDIO and SWCLK to PMUX=A, and also change them to regular pins and configure them as outputs.

But all of that gets superseded by the reset extension.

I would need at least some code snippets from the code you are using. Or a binary will work.

[biboc]

Ok thanks for the test

I may have an idea. I do think that my main problem is not edbg software but the fact that I use a Supercapacitor and EDBG chip boards does not provide sufficient power. With an external source, it works and I can't find the problem I mentioned earlier again.

I'll do more tests and tell you if we can close the issue