Getting started with stm32 or don't repeat my mistakes

A short story about the rake encountered on the way of knowing ARM on the example of stm32f103c8t6 and stm32l151rct6.

My acquaintance with microcontrollers began with AVR. I worked on them for quite some time, going from the boards with scratched tracks and assembler in AtmelStudio4 to normal loot and self-written makefiles for working in notepad (in my case, KWrite) and the command line.

But it's time to poke a stick in their older brothers - ARM. The choice of a specific family was long and passive (because there is no direct need, so I was in no hurry), but in the end it ended up on stm32f1, as it was, perhaps, the most popular one. Buy a programmer, debug board like Discovery or blue pill? What are you, I'm a master in AVR-cams! Any board can be made LUT, and even as you need, without too much body kit. Therefore, I buy a bare stm32f103c8t6 and start shamanizing with the trace of the board. What will I need? At least two ports should be brought to the combs ... oops, it is inconvenient to display the ports entirely. Oh well, I’ll get 8 legs each - from the port A the younger ones (0-7), from B the older ones (8-15). Still, of course, LEDs and buttons, as without indication and control. Here's what surprises me in the finished debug boards is the lack of at least 2-3 LEDs and 1-2 buttons that would not conflict with anything. How do they imagine debugging? Under the buttons PA8, PA9 themselves are asked, they are conveniently located. USB, jumpers BOOT0, BOOT1 and a battery connector for watches are also useful. And connectors for quartz, so that it’s very beautiful (I have never used the connectors for quartz afterwards). For power supply, the controller needs no more than 3.6 V, and with USB comes 5 V. It is necessary to install a stabilizer. I read a lot how people choose stabilizers with a low voltage drop ... why? The difference is one and a half volts, but there is enough oak 78l33. And now the JTAG connector. Atmel's programming connector had a standard ISP10 or ISP6. Probably JTAG is also a standard thing. It turns out yes ... but only for a single manufacturer or even a device. We look at the connector on st-link: beautiful, 10-pin. We look at some programmer for AVR: oops, already 20-pin. We look somewhere else: more incompatible connectors to the god of incompatible standards. Well, if so, we will invent our own. If anything, the adapter between them will be no more complicated than the ISP-6 to ISP-10 adapter. Everything seems to be ready, you can make a fee. As it turned out, a pitch of 0.5 mm is quite achievable at an amateur level, I didn’t even have to paint with a marker.

Now how to flash it. Since there is USB, it is probably able to through it. I read the datasheet - yeah, it can’t do it via USB, but it can do it via UART1. Oops, I forgot to withdraw it. Moreover, it also conflicts with the button, with the one that hangs on PA9. Well, okay, I’ll output it on postings, but there’s still one more button. A little shamanism and the board is ready and even defined in stm32flash.

It seems to be sorted out with iron, it's time to move on to the code. After reading several articles on the Internet, I found a ready-made archive under gcc-arm-none-eabi. I will figure out exactly how to set the assembly sequence later. So far I’m doing hello-worlds on buttons and LEDs. Since this is my first acquaintance with this family, no wrappers like HAL are just manual work with registers. However, this is a completely natural approach, it seems to me, one could not mention. It annoys me a little bit all the time to pull the power and BOOT0 on the board, but oh well, someday I will make a JTAG programmer. Oddly enough, I didn’t step on the rake with the clock turned off. He recalled his youth when he wrote 3D-processing on TurboPascal. Here I have a display on ili9341 from raspberry pi and a controller at as much as 72 MHz. That's what happened - up to 200 points per model and 11 fps. Of course, all transformation matrices are counted in fixed-point numbers.

At some point, I wanted to make a wearable device to work for a long time on battery power. I looked at the datasheet and was upset: the famous ARM in consumption is many times worse than the same AVR-ok! If the latter (poked at the first controller that turned out to be ATmega88p) had a consumption of 0.8 μA, taking into account the hours, then the first even in the most economical sleep mode * had 25 μA ± 1.4 μA at RTC. This is no good. However, stm32f103 is not positioned as an economical series. I look at the STmicroelectronics website for other series of controllers and choose the stm32l1 series: in addition to consuming about 1 μA, there is also a capacitive sensor and an LCD controller. True, the maximum frequency is lower, only 36 MHz (or 24 MHz if USB is used), but I’ll survive it somehow. It was decided: I take a couple of stm32l151rct6 right from 32 kB of RAM (there’s also 256 kB of flash, but I have little idea of ​​how to score it. Is that really wild shit or data sets).

• ) do not confuse sleep modes (sleep, stop) with shutdown (standby)

In parallel, I make the st-link v2 programmer from the spare stm32f103, simply because I'm tired of messing with BOOT0 and power, and it’s faster. However, I will leave UART programming - you never know what. There was also a bit of shamanism, but nothing outstanding. Unless finding the command line for openocd turned out to be a problem. For future generations I will leave her:

openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg -c "init" -c "reset halt" -c "flash write_image erase "$(firmware).bin" 0x08000000" -c "reset run" -c "exit"

For stm32l151 it is necessary, of course, to correct target to "target / stm32l1.cfg"

I’ll run a little ahead in chronology, but not to come back. Gentlemen, do not save on the thickness of the PCB! Or at least add props, or do not use smd components. It so happened that on the programmer board I provided only two mounting holes in random places. And the places were quite far from the JTAG connector. And after some time I noticed that the programmer is unstable. That works, then no, then through UART you have to erase the "victim", then pick it up. It turned out that the resistor coming from the controller output to the connector broke. He just fell off the contact pad from the body. I soldered the resistor. Then he soldered the rest. Then he realized that even that small deformation of the board that arose during the sticking-pulling out of the cable was enough for the unfortunate components. As a result, I stuck a backup right next to the connector. While holding.

As the reader has already guessed, programming is also in a text editor, while compilation and firmware are in the console. Naturally, the purchase of a debugging board for l151 inspired me no more than any IDE. Rubbing the traces of the rake left by the first board, I breed the second (considering the programmer as the third, but it's still not a debug board). Since I was going to debug an energy-efficient device, I need to bother with power. I won’t change the 78l33 stabilizer, but I tore its output with a jumper so that I could poke it with an ammeter (I hope all the same for a microammeter, but there it goes). Let the combs be the same as on the previous board - compatibility! Well, a couple of LEDs and buttons, of course. The rake with UART1 shines invitingly, but I still put its connector and do not get it on the forehead. Of course I already have JTAG, but insurance does not hurt. Just like the previous one (and the programmer board, too), it was possible to separate on one side, even there are not too many jumpers.

But when the controller was sealed, a problem arose. I somehow naively believed that there should be a key on the body of the microcircuit indicating the first leg. Who would expect that well done from ST will make TWO keys, symmetrically. So which side to solder it now? Thinking, I decided that these were not keys, but technological deepenings. You never know, for positioning the chip in the manufacture, for example. Or press the base to fill with plastic. Then you need to navigate by the inscription. It is logical that the inscription should be readable if the microcircuit is positioned “standardly”, that is, when the first leg is in the upper left corner. So he began to solder. Either a LUT defect, or crooked hands, but the microcircuit was soldered crookedly, I noticed it in time, before I completely soldered it. It doesn’t matter, there is an old way to solder millipedes using a razor blade: it is not wetted by solder and thin enough not to bend too much. It turned out that the hands are still not straight enough, because the legs are bent. But not up, but sideways, well, at least not very well, and they managed to somehow straighten them. The second attempt to solder was already under the microscope, but before that I decided to correct the legs. And one of them broke off. What are they made of, that you cannot bend-bend once? The output components have no such problem. Well, that’s it, I think the chip in the marriage will have to solder another one. But suddenly this is not a critical leg? Well there, a general-purpose conclusion, or one of the meals. So far I have sealed without it, and there it will be seen. This time I managed to solder evenly, though the leg got on I2C, with which I wanted to have fun, but at least not on vital connectors like USB, JTAG, UART or BOOT. I connect it - it does not work, the programmers do not see the board. For some time, the shaman with soldering legs, but it does not help. A glance at the datasheet stumbles upon a picture of the controller located somewhere in the basement of the document. Here's how you could come up with the inscription BOKOM ?! That is, if you turn the controller so that the inscription is read, the first leg will be in the lower left corner. Along the way, it turned out that one of the "technological recesses" is still the key. True, it does not explain how to distinguish it from symmetrical ... Well, at least some clue. I solder the controller with a building hairdryer so as not to break the conclusions, and this time I solder it sideways. The broken output goes exactly to the TX output of UART1, that is, to the programming and debugging connector. This is not good at all, but before changing the controller, you must at least make sure that with the orientation I guessed that when soldering to live, do not kill it with an incorrect connection. I connect the programmer - it works. Hurrah. There are little things left - solder the connectors, diodes and other harnesses. The comments suggested another way - ring the earth: they are usually connected inside the case and are not located completely symmetrical. True, given the step of conclusions, getting to the right conclusions can be difficult. Be that as it may, this is the most reliable way.

I don’t want to work with the controller without UART1, and it’s even worse than now. And if it does, it’s all the same to change, so I decide to play a surgeon and make the controller a prosthetic leg from the hair of MGTF. Just at hand lies a good electrically conductive glue, with which the hair decisively sticks to the platform on the chip body. That glue that got on neighboring legs is ruthlessly removed with a scalpel. And what do you want to get into the half-millimeter platform and not get into the adjacent protruding legs? I check - it works. Until it falls off, and so as not to fall off later, pour cyanoacrylate.

Perhaps this is how I would have used this board if the leg hadn’t fallen off again. And it is covered with glue. However, it is quite soft and cut with a scalpel, so it is successfully cleaned off. But for some reason I do not want to use the same electrically conductive adhesive for the second time. I'll try to solder the leg. The usual tip of the soldering iron did not crawl into it, but the cone was included in the kit (in fact, the cone was originally the only one, but due to its obvious inconvenience, it was replaced by the usual one, with a wedge-shaped sharpening), which completely creeps into it. Oddly enough, the “transplant operation” was successful and the leg worked as it should (a close-up photograph of the leg on KDPV).

So, the iron is ready, it's time to go to the code. It would be nice to find a ready-made example under gcc and the CMSIS library. What is better for this than the official website of the manufacturer? As it turned out, STmicroelectronics do not share my optimism. The fact that the navigation on the site is done through an indecent place is already familiar, it is now difficult to find a site made by people for people. But they do not allow anything to download from the site! Perhaps they would allow it after registration, but before that I didn’t have a desire to register anywhere, and after such an attitude towards developers, even more so. Why the hell do you need my mail or what do you demand there? Collect personal data, send spam? Go through the forest, and I will find it in the public domain! By the way, I was a little surprised that the corresponding package was not in the repository, but perhaps ST came up with some kind of licensed hemorrhoids.

Be that as it may, the library was perfectly found on the Internet (I won’t give any links, you never know what will happen to the site). An alternative is to download the development environment or CubeMX, where these libraries are embedded. True, downloading them from the official site is just as impossible, so we are looking at third-party ones and installing them on a virtual machine, just in case "if something happens."

We figured out the iron, and the sorts, too. It's time to finally deal with the controller. The first surprise was waiting when trying to use third-party code under Discovery. They used the stm32l152 controller, which at first glance is almost the same as the stm32l151 that I installed. In addition to minor differences, it turned out that the LCD module was not installed in the "my" controller. A little disappointing, but I still did not plan to use it. Although such a difference could have been more clearly distinguished than a footnote in the datasheet. By the way, in a datasheet, it is recommended in this case to connect the VLCD pin to the power supply, in my photo the corresponding 0-ohm resistor is not soldered, but in reality I installed it. Without it, it also works, but do not overload the internal connections. The behavior of the real-time clock turned out to be more interesting. They stubbornly did not want to work, and on the Internet they write simply "do it, do it, it works." But it does not work. In some places, however, mention was made of "known problems with RTC in this series." Be that as it may, the watch still wound up, though only on the built-in RC generator. Attempts to lock clock quartz led to the endless wait for the LSE readiness bit. I tried to check if the legs of the microcircuit had fallen off the tracks on the board and pulled them in normal GPIO mode. High-frequency quartz fell off. WTF ?! In general, these two quartz do not want to work together, but at least separately they function at the very least. the watch still wound up, though only on the built-in RC generator. Attempts to lock clock quartz led to the endless wait for the LSE readiness bit. I tried to check if the legs of the microcircuit had fallen off the tracks on the board and pulled them in normal GPIO mode. High-frequency quartz fell off. WTF ?! In general, these two quartz do not want to work together, but at least separately they function at the very least. the watch still wound up, though only on the built-in RC generator. Attempts to lock clock quartz led to the endless wait for the LSE readiness bit. I tried to check if the legs of the microcircuit had fallen off the tracks on the board and pulled them in normal GPIO mode. High-frequency quartz fell off. WTF ?! In general, these two quartz do not want to work together, but at least separately they function at the very least.

And then I guessed: superglue, which was filled with half of the controller (it's liquid, you can’t apply it precisely, and who would have thought ...), gives a leak and quartz interferes with their tips. Well, it’s not difficult to scrape off the glue from the outside, but after all it’s numb even under the bottom of the chip. And if there are enough leaks on it for quartz, then it will affect consumption. I am looking in Google, than people remove cyanoacrylate. It offers warm water (what ???) and dimethyl sulfoxide. I do not believe in warm water, so I buy DMSO. After more than an hour of finding a drop of chemical on the surface of the glue, I did not notice the difference. But they noticed quartz and began to work more or less normally (I wonder why? Dimexide replaced the moisture absorbed by the glue?). However, this did not convince me, and the remnants of glue are still an eyesore ... for nothing that are on the underside of the board and are not particularly visible. By the way, the warm water that I washed off with dimexide did not affect the glue (I'm not surprised). I discovered that there is such a thing as a glue remover, in the same tube as the glue itself, only in purple. Well, at least it should work! As it turned out, it can and does work, but its consistency resembles sour cream and simply does not fit under the microcircuit. Well, what's the use of you, eraser ?! Outside, I can clean it. Last chance: acetone is rarely mentioned. I am a little afraid for the plastic parts, but just replacing them is easy. I pour acetone into a glass jar, throw a board there and leave it overnight. The next morning it turned out that acetone really works, and how! There was no trace of glue. Moreover, the pusher of one of the buttons dissolved. Interestingly, the second survived, probably, was made of more stable plastic. I was a little surprised that other plastic remained untouched, even the inscriptions survived. Well, excellent, but the button can be replaced.

Now we managed to launch RTC from the watch quartz, and touch the sleep mode, and communicate with other peripherals. And also, so that it was completely feng shy, he applied signatures to the board. But not with a marker (suddenly bathe again in solvents?) But scratched with a scalpel. For centuries!

Well, for future generations, I’ll leave code examples for both controllers, along with libraries, makefiles, and more. It remains only to install gcc-arm-none-eabi, openocd, stm32flash and other trifles.
stm32f103
stm32l151

In the comments, they were advised several times not to do LUT and order the manufacture of boards from professionals. For prototyping, as here - I see no reason. Another thing is if you need a multilayer board, or an even smaller step, or a BGA-case, or something else that is difficult to do at home. And, of course, in the manufacture of the final version of the device and replication. It is not good if the customer disassemble the casesoldered from PCB, and it will find out a crooked sawn-off board without a mask and with jumpers from MGTF.

Conclusions:

1. You can make debugging boards for yourself if you wish, they are no worse than purchased ones. But the debugger programmer is still better to buy if it is not too expensive. Of course, you can make it, but you will not change the scheme, and if so, it will not be better than the purchase. Cheaper, most likely, too. Unless the superfluous controller remains or with a delivery problem.
2. Do not forget about the backup programming connector UART1, well, at the same time, jumpers BOOT0, BOOT1. In addition to the actual programming, it is quite convenient to debug a program using UART.
3. There are two keys on the LQFP64 case, one of which is fake. You will have to navigate to the inscription so that you look with your feet to the left.
4. Soldering components with a small step is only under a microscope. Otherwise, it is difficult to determine whether everything has disappeared and whether there are "snot". Well, either on "professional" equipment like a special hairdryer, solder paste, etc. I don’t know here, I'm writing about amateur technology.
5. Do not save on PCB thickness. It bends and this may be enough to damage smd resistors and, probably, capacitors. This is not scary to the output, and components with bent conclusions (transistors, microcircuits) will probably survive.
6. Making connectors for quartz is a waste of time. You will not change them, so just solder on the board.
7. Drinking a millipede with a razor blade is only in the most extreme case, when there is no hairdryer. Otherwise, the risk of damaging it is too great.
8. Even if the leg has fallen off the microcircuit, it can be restored! Even when the pitch is 0.5 mm. The main thing is to use soldering, not conductive glue.
9. Never fill the chip with cyanoacrylate glue (super glue)! He does not have the proper electrical, and indeed mechanical, characteristics.
10. Acetone is best suited for removing superglue from hard to reach areas. It dissolves completely. The main thing is to make sure that the surrounding components are not affected. From non-hard-to-reach places can be removed mechanically.