2
\$\begingroup\$

I use a SAMD21 without an external crystal, by using its internal 32kHz oscillator and transform it with DFLL to 48 MHz.

The processor wakes up normally with GCLK0 on 1 MHz, so I first activate GCLK1 with 32 kHz, switch the processor to it so I can turn off and reconfigure GCLK0 to DFLL 48 MHz, and then switch the processor back to GCLK0. (this is the same method the Arduino Zero does, with the single exception that it uses the external 32k resonator, while I use the internal one)

I now have GCLK0 running on 48 MHz and driving the CPU. I also use the generic clock 2 on 1 MHz for PWM, UART, and other things. So far so good. I debug it with SWD, with the use of an XPlained Pro board where the microcontroller has been removed and the SWD lines go directly to my board.

Everything worked fine. Until I wanted to set up the generic clock 3.

REG_GCLK_GENCTRL = 0x000003; // disable gclk3 to allow changes REG_GCLK_GENDIV = 0x000103; // set division to 1 REG_GCLK_GENCTRL = 0x010603; // activate gclk3 with 8 MHz

After uploading the software, the microcontroller became unresponsive and I can no longer access it via SWD. I had a spare board, and foolishly tried it as well. The same thing happened.

The error says

error: Could not activate interface, but found DAP with ID 0x....

It suggests erasing the flash and names deep sleep as a possible cause. I can erase the flash successfully. However, no other operation is possible.

My first guess was that I somehow messed up the clock settings, the CPU needs a running clock to be able to be accessed via SWD, and it cannot do so for the lack of a resonator. So I took out the resonator from the XPlainedPro, and installed it into my board the exact same way it was in the XPlainedPro, including its capacitor.

It didn't solve my problem.

I've seen this error in a few threads, but usually it's about JTAG not working while SWD continues to work.

I there a way to save my controllers, or are they bricked?

\$\endgroup\$
3
  • \$\begingroup\$ The SAM 4 chips have a hardware erase pin, does the SAMD21? \$\endgroup\$ Commented Mar 19, 2018 at 15:59
  • \$\begingroup\$ No, they only have a reset pin. \$\endgroup\$ Commented Mar 19, 2018 at 16:02
  • 1
    \$\begingroup\$ Yes, was just seeing that in the data sheet. Probably worth reading the section on "Cold Plugging" an SWD adapter which appears to be the Atmel terminology for what Arsenal's answer describes in ST micro style "connect under reset" terminology. \$\endgroup\$ Commented Mar 19, 2018 at 16:06

1 Answer 1

Reset to default
2
\$\begingroup\$

I have no experience with the SAMD-devices, but from my experience with other controllers I would say:

If you would have erased the flash successfully there would be no program to set the clocks, so the device would become accessible after a power-cycle. I doubt that you deleted the flash.

In especially hard cases (I once disabled the SWD pins accidentally as first instruction in my controller) connecting the reset pin to the debug interface usually helps as there often is an option called "connect under reset" or something like that. The debugger will then make use of the reset pin to get into the device even if the software running on it would prevent it otherwise.

Note that it is important that the debugger has control over the reset line as just holding it in reset will prevent the controller from running. Depending on how fast your program gets to the bricking point you might get away with a good timing between manual release of reset and clicking connect on the PC, but that is usually very inconsistent.

Sidenote:

REG_GCLK_GENCTRL = 0x000003; REG_GCLK_GENDIV = 0x000103; REG_GCLK_GENCTRL = 0x010603;

Who the hell is supposed to understand what you are trying to do here? Use predefined values for setting register values for hardware. Something along the lines of GCLK_GENCTRL_GCLK3EN or whatever will make it much more understandable. I'm not going to look up all those bits you are messing with. This introduces a hell of possible bugs because a small shift error will cause disaster.

\$\endgroup\$
5
  • \$\begingroup\$ Indeed, this might mean I'll have to invest in a proper debugger, as the options the demo board provides are quite limited. \$\endgroup\$ Commented Mar 19, 2018 at 15:57
  • \$\begingroup\$ Regarding your side-note about the magic numbers: it's a peculiarity of this chip why it has to be done like this. In all other cases I use nice structures like SERCOM0->I2CM.CTRLA.bit.MODE = SERCOM_I2CM_CTRLA_MODE_I2C_MASTER_Val; However, here all the bits of different registers packed into one 32-bit register have to be set at the same time. Until I'm ready with the final setting, it's much quicker and clearer for me to work with this bit pattern than with a lot of constants OR'd together. \$\endgroup\$ Commented Mar 19, 2018 at 16:01
  • 1
    \$\begingroup\$ @vsz well if you think so. It's just that "working" code sticks and you are likely to never go back and make it right after it works. Then you revisit it half a year later and find a mess of magic numbers. But let's leave it at that. I don't know the Atmel environment, but for the STMs I'm working with there are very inexpensive tools (~20€) available which already provide this feature. \$\endgroup\$ Commented Mar 19, 2018 at 16:10
  • 1
    \$\begingroup\$ The EDBG chip with its reset line connected to my controller solved the problem. The "bricking point" was an interrupt which was triggered on a peripheral which didn't yet have its clock properly started. \$\endgroup\$ Commented Mar 20, 2018 at 5:57
  • \$\begingroup\$ @vsz glad you got it working again. \$\endgroup\$ Commented Mar 20, 2018 at 8:32

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.