How to kill microcontroller with standard settings. Part 2

Not so long ago, I wrote about how I managed to turn a microcontroller into a "brick" by setting an unsuccessful combination of settings. The problem was that I accidentally managed to enter into the on-demand operation mode a generator that clocks the controller core. At the same time, everything was turned off, including the debugging module. A lot of people responded to my request and gave me some practical advice, and many still ask how it all ended. So the story developed quite comically, but ended very banal. Details under the cut.

So, following the advice of experienced people, we went to re-read sections in the User Manual on debugging and controller boot modes. It turned out that there seems to be a boot mode in which the controller does not start executing the code, but waits for the debugger to connect.

The most difficult thing remained - to solder to the necessary pins in order to correctly execute the boot sequence. The equipment that allows us to do this and not kill the board is in our other office, so we had to go there and give everything to specialists ...

But on the day we were about to take her, something inexplicable happened. In the evening, the board was put in a bag, then in a box, and the box was put into a bag. However, in the morning there was no board in the bag. She just disappeared! We rummaged through the entire bag, all the boxes that we found, turned to the lost property office on the buses in which the bag was traveling ... All in vain. Having spent a couple of days searching, we decided to spit on this board and wait until new ones are manufactured (which is almost 4 weeks). It’s good that we were able to continue working with the firmware, since we had an Arduino M0 with a similar processor.

At that moment I recalled a joke about a Russian and two titanium balls, but it was somehow not funny.

However, as a result of another brainstorming session, we remembered that before leaving home with the board, the tables were cleaned. We ran to the cabinets with the details, and, taking a break from the bottom to the top, we found the loss in that bag. It turned out that someone accidentally at the last moment took the board out of the box and removed it to other parts. Then they closed the box, put it in a bag, etc. Now, the joke was already perceived not so sadly.

As a result, having spent another day soldering the necessary wires, we began to revive. Here it is worth saying that while we were having fun searching for a board, J-Link came to us. True, not the original, but a cheap analogue of an unknown manufacturer.

So, as it turned out, there was no need to even solder anything. This J-Link immediately saw the microcontroller, although the expensive and more sophisticated ULink refused to do this all the time.

After the ill-fated firmware was erased, everything fell into place and all debuggers were able to connect to the controller without any problems.

We assume that we were saved by the fact that J-Link is able to clock the debugging module itself bypassing the kernel. I do not know the SWD specifications and did not understand deeply the difference between J-Link and ULink, but it seems that a cheap analogue works better than an expensive and sophisticated one. However, at the same time, it regularly burns out ...

This is where the story ends. The board works, the firmware is being written. Thank you all for your help!