How to use the standard settings to kill the microcontroller. Part 1

I can not call myself a very neat and attentive person, but nevertheless, for more than 10 years of software development for embedded devices, I really did not manage to burn or spoil anything. On the one hand, it’s worth saying "thank you" to my colleagues - circuit engineers. On the other hand, modern "smart" microelectronics has a rather serious "protection against a fool." But a couple of days ago there was one interesting case. I managed to turn the Atmel SAMD21G18AU microcontroller into a “brick” by performing the usual manipulations described in the user manual.

It so happened that since my student days I was taught that "only amateurs work with Atmel", so you should not use it. The argument is very doubtful, but according to the principle “I did not read it, but I condemn it”, the dislike of Atmel was also transmitted to me.

However, at one point, another customer came to us and brought a draft of the device, which needs to be improved and for which you need to write a “firmware”. The core of this device is an Atmel microcontroller SAMD21G18AU. So I had to throw away my prejudices and start exploring this crystal.

The microcontroller turned out to be quite famous and widespread thanks to ArduinoZero .

After studying the general parameters, I was very impressed. The controller has little in common with the old Atmelovian families, works on the Cortex M0 core and uses a sophisticated system of configuration of the periphery, of which it has a lot.

This system allows you to flexibly adjust the crystal to a wide range of tasks, but it also increases its "complexity" and negatively affects the learning curve of working with it (I do not take Arduino IDE into account :).

Atmel also has its own software library for working with its Atmel Software Framework microcontrollers. It's a good thing, until you start using it :) The library is designed to work in IAR and Atmel Studio and contains a huge number of drivers, modules and examples for almost all Atmel controllers ... But in my opinion, it is designed and documented badly enough (try to deal with it yourself)

The architecture of the library is designed so that everything is tied to the debug boards:

That is, to use the library for your own board, you need to make its "description" in a certain format (very vaguely documented) and fix a couple of files (in particular, board.h). At the same time, if you just want to take a specific driver and use it in your project, then you will encounter serious difficulties. Especially if your project is not made in IAR or Atmel Studio. We'll have to rake the dependencies of the modules for a long time and isolate the necessary files.

This process ruined my copy of the controller. I needed a watchdog driver. He, in turn, pulls several other drivers, including the Clock driver, which is engaged in setting up clock generators for both the core and the periphery. Well, Clock uses a special .h file containing the generator configuration for a particular device. And I was so "lucky" that I didn’t get the wrong file that eventually turned off the core clock generator and, at the same time, the module for working with SWD.

SAMD21G18AU has two built-in clock generators and allows the use of two external. The GENERIC CLOCK CONTROLLER module incorporates several internal generators. The first of them clocks the core, the rest are used to clock the periphery. For each internal generator, you can set the source (internal or external), the multiplier and other parameters, among which is "OnDemand". It allows you to run the generator "on demand", thereby reducing system consumption.

After rebooting, the SAMD21G18AU default tunes the core to 8 MHz from the internal oscillator, and disconnects the remaining generators.

The file I’ve got is forcing the Clock driver to set the core clock to an internal 8 MHz oscillator, but at the same time it switches it to the “OnDemand” mode. But for some reason this mode does not work and the generator does not start. It turns out that as soon as the controller starts to execute the code, it disables the clocking itself.

At the same time, the module for working with SWD also ceases to be clocked, which means that it stops responding when trying to connect. And no tricks are helping to catch the moment when the processor has already turned on, but has not yet had time to work out the curve setting of the GENERIC CLOCK CONTROLLER module.

It would be possible to use a flashing through the bootloader. Usually, microcontrollers have a wired bootloader that allows you to program it at least via a COM port. But it was not there! Atmel outwitted himself. Although the use of the bootloadr is provided for , but due to the “flexibility” in the settings, the place reserved for it can be used to store the executable code. And it looks like this is the default setting.

That is, to work with the bootloader, it must first be “sewn” into the controller. And of course, in my case it was not done.

The funny thing is that although both external quartz are soldered on the board, in the end, neither works. It is impossible to approach the controller either through SWD or via Bootloader.

In conclusion of the story I want to say that I still do not have deep skills in working with this microcontroller, so perhaps there is a way to “revive” it. Maybe someone will tell me a solution to the problem, until we soldered the "brick" and did not solder the new SAMD21G18AU?

ps Well, my dislike of Atmel got the first argument in its favor. The controller, which allows you to drive yourself into a dead end by a combination of settings, while not having full-time recovery tools - this is somehow not solid ...

Update:

Read the story here .