Understanding datasheet of STM32C031C6T6 MCU

[sairfan1]

I have past experience working with PIC 8 bit MCU, I understand to go through datasheet and understand registers to setup peripheral like SPI, UART etc.

I recently bought ARM based modules with STM32C031C6T6 on it, when I looked at its datasheet (attached) it does not have enough information like registers and configurations for SPI, UART etc. looks like its not a datasheet rather its a summary, but I downloaded same datasheets from ST, Digikey and Mouser websites and found the same.

Looks like I do not understand ARM/ST MCU world, I was looking for help to get this basic understanding.

[squadchannel]

check the reference manual.
https://www.st.com/resource/en/reference_manual/rm0490-stm32c0-series-advanced-armbased-32bit-mcus-stmicroelectronics.pdf

[fourtytwo42]

Welcome to the world of digging hard for information! If you are lucky you might be able to find the reference manual for the chip.
That at least gets you as far as register definitions BUT don't try and use those in C as they do not provide any nice simple header files like Microchip do.
Instead you are supposed to use some god awful garbage called HAL to define your io's and it I believe then generates so called code for handling them.

I too made the mistake of buying one of those ARM modules, it remains after several attempts at use over the years in the bottom of a drawer.

[prints-f-darkness]

Hi, I feel I can contribute something to your topic/question.

First and foremost, the hardest part of programming the stm32 is the HAL (Hardware Abstraction Layer), thankfully! I have found a great resource to help me, and hopefully you. https://leanpub.com/mastering-stm32-2nd , the 30 bucks is well worth it. The book goes over setting up the programming environment and peripheral programming. "Why do we need a hardware abstraction layer?" I hear you ask, well, you can use the same code-base over multiple chips without register conflicts. Kinda brilliant, and I'm all for it.

also as mentioned, the programming manual is a great reference. I recommend downloading all documents on the devkit page. https://www.st.com/en/evaluation-tools/stm32c0316-dk.html#documentation
and the chip page https://www.st.com/en/microcontrollers-microprocessors/stm32c031c6.html#documentation

I can point you to the answer, but its still up to you to read, play, test, and get frustrated while learning.

[mwb1100]

I recently bought ARM based modules with STM32C031C6T6 on it, when I looked at its datasheet (attached) it does not have enough information like registers and configurations for SPI, UART etc. looks like its not a datasheet rather its a summary

For more complex microcontrollers, the datasheet is a summary.  The details of operation are provided in a separate reference document.  However since the reference often applies to a family of devices, there are usually important details in the datasheet that aren't in the reference document, such as pin outs or a memory map.  Also, often neither the datasheet or reference manual will not go into detail on the instruction set - for example with ARM based microcontrollers you would be expected to refer to the appropriate ARM reference.

[harerod]

To summarize:
- the datasheet (by ST) gives you mostly electrical information
- the reference manual (by ST) gives you information about the peripherals
- the programming manual is based on information from ARM and contains information about the CPU core and NVIC
- application notes (by ST) give additional information, e.g. how to setup the ADC
- errata (by ST) - read those before ordering your new PCB and pray that you will not be the proud discoverer of an unknown bug. There is a reason why people prefer to stick with known silicon.
 
Understanding a modern MCU requires a rough idea about the contents of all the relevant documents. During implementation you refer to the few hundred (out of thousands) pages that are relevant to your current project. Still daunting, but much better than when that device family was new. Lots of stuff online.
Expect several months of learning. If this is commercial project - try to get assistance for your first designs.

Edit: typo

[thm_w]

Welcome to the world of digging hard for information! If you are lucky you might be able to find the reference manual for the chip.
That at least gets you as far as register definitions BUT don't try and use those in C as they do not provide any nice simple header files like Microchip do.
Instead you are supposed to use some god awful garbage called HAL to define your io's and it I believe then generates so called code for handling them.

I too made the mistake of buying one of those ARM modules, it remains after several attempts at use over the years in the bottom of a drawer.

The simple header files are called CMSIS, and there is also LL: http://www.alexandre-boyer.fr/TP_LoPoSo/Overview_LL_Library.html
If you couldn't figure out HAL there is not much hope in you figuring out either of these though.

https://www.reddit.com/r/embedded/comments/18g3aae/stm32_learning_curve_for_beginners/
https://wiki.st.com/stm32mcu/wiki/STM32StepByStep:Getting_started_with_STM32_:_STM32_step_by_step
https://pomad.cnfm.fr/PoMAD/tutorials/stm32

[Siwastaja]

Welcome to the world of digging hard for information! If you are lucky you might be able to find the reference manual for the chip.
That at least gets you as far as register definitions BUT don't try and use those in C as they do not provide any nice simple header files like Microchip do.

Totally unjustified rant: ST reference manuals have been always easily available on their website, and Google finds them well too.

ST also has normal header files defining the register names just like Microchip does on PIC. Google finds those as well.

Instead you are supposed to use some god awful garbage called HAL to define your io's and it I believe then generates so called code for handling them.

Of course not. Using trend-framework-HAL-whatever of the year is optional, and I encourage not to do it, but continue the PIC way. I never even considered anything else. You can program these things by header-only register-access only type programming just fine.

I too made the mistake of buying one of those ARM modules, it remains after several attempts at use over the years in the bottom of a drawer.

I think really the only issue - the one you did not mention in your rant - is poor availability of complete minimal examples that would run out of box. Documentation is all there, tools are all there - only, good examples are hard to find. This is why I wasted like a month working with a broken linker script - and your board remains in the bottom of a drawer.

It's sad, because these more advanced microcontrollers really are not much more difficult to use (and in some other ways, they are much easier), but people still live in made-up misconceptions like you well demonstrate. And I'm not saying it's your fault, it really is not. No one told you it really is easy, and no one showed you a working simple example. Instead, everyone shoveled metric shitton of overcomplicated bullshit down your throat, and still do even on forums like this.

Meanwhile, since I got into ARM land I have been able to switch microcontroller manufacturers with extreme ease never experienced before. No need to download any manufacturer tools, IDEs, compilers, nothing. Just the PDF, text editor and GCC/binutils, but yeah, the PDF might be divided in two files instead of just called "datasheet".

[sairfan1]

Meanwhile, since I got into ARM land I have been able to switch microcontroller manufacturers with extreme ease never experienced before. No need to download any manufacturer tools, IDEs, compilers, nothing. Just the PDF, text editor and GCC/binutils, but yeah, the PDF might be divided in two files instead of just called "datasheet".

Can you please explaine a little bit, like what should be the sequance of learning, i do not have that in depth understanding that i can configure linker or other compiler modules to combine missing puzzles

[Siwastaja]

Meanwhile, since I got into ARM land I have been able to switch microcontroller manufacturers with extreme ease never experienced before. No need to download any manufacturer tools, IDEs, compilers, nothing. Just the PDF, text editor and GCC/binutils, but yeah, the PDF might be divided in two files instead of just called "datasheet".

Can you please explaine a little bit, like what should be the sequance of learning, i do not have that in depth understanding that i can configure linker or other compiler modules to combine missing puzzles

I think ataradov has some decent starter projects (examples):
https://github.com/ataradov/mcu-starter-projects

I have not personally tried those, so YMMV.

Basically, you need a working
1) linker script
2) startup code
3) LED blinker code

to get going. After that it's pretty much reading the reference manual and adding functionality.

I did waste a lot of time initially (over a decade ago, with STM32) because I had a broken linker script, taken from a well-intended, otherwise quite helpful tutorial. It was a big time sink which but ended up being just one freaking single number wrong (stack pointer aligned(4) when it should be aligned(8))! But stuff like that can be pretty demotivational so I'm not surprised about fourtytwo42's conclusions.

[PGPG]

After that it's pretty much reading the reference manual and adding functionality.

It is the state I am also just coming to.

I will wire some sentences that may be you find being interested and may be seeing our needs you can just write information about ST I will be searching next weeks.
I may be wrong everywhere because I am describing something that I did not do - I have never written even a LED blinking microcontroller program. Only what I have in common with microcontrollers programming is that at the beginning of 90s I have written 8051 macro-assembler that since than was used by my brother instead of other he had (my simply was better ).
Since about 2010 we used AtXmega programming them via PDI with whole program at once.
During first Covid19 isolation we were just developing the different way - initial program programmed by PDI and the rest by this program. What was needed - programming bootloader flash not from PDI but from program working in program memory (to distinguish it from bootloader memory) and burn the protective fuses from inside. We were not 100% sure if it is possible but found that it is.
Then AtXmegas suddenly disappeared from market and to save ourselve from a trap we had to fast move to 32bit we were planning since few years. With ST there were also problems. My brother selected Silabs microcontrollers. But it were times when you couldn't check everything with prototype because when you were ready IC you wanted could be not accessible. So we first bought enough stock (based on our assumptions on what we need) and then started development.
First problem my brother had was with USB. I think there were not enough documentation. They simply assumed you use their library, but the library code (was much, much bigger than we supposed such program can be) together with our program were bigger then half of flash. We always use only half as second half is to collect upgrade (upgrade process takes place in the background of normal operation). And also program liked to hang. My brother started to go through their library reducing at the end its size probably more than 5 times and founding there a bug that explained why their own debugging (driven by USB) hangs from time to time (assuming that they use their own library). This processor were programmed through USB so we were able to do both steps by us.
With next processor programmed by 2 wire debug interface we failed with programming through it. Fortunately we had our two-step solution so we used the way that first step with their programmer in development PCBs and the second stage could be done by this first program working. If we had no this two stage we will be not able to program it safely (having keys only temporarily in RAM and not written into files at HDD).
Next we selected the other microcontroller only based on description what functionality it has and this time we had to buy enough stock and then when we started to develop we get into something we never, ever expected in any microcontroller documentation can be found. The crypto-co-procesor was nowhere documented. In the place were their registers should be listed there were some sentences telling that we are too stupid to use it and should use their library written by enough clever people. And the library (like that USB one) was huge, once more (we didn't foresee enough memory for this). My brother had to go through it to find how to use this co-processor (we don't need such stream encryption as that library was concentrated at). So next library was replaced by something 10 times smaller.

Few days ago my brother selected one of ST32 M0 microcontrollers (we have never used any from ST32 family) and in few weeks I have to make prototype board. Just today I have send mail to me to have at weekend at home its type so may be will find time to collect pdfs to be read. With Silabs it was not easy to first decide what I have to connect around (specially for example what to do with integrated in microcontroller DCDC when I don't want to use it - what connect, what not connect, where and what capacitors. I was also surprised that one microcontroller assume quartz (don't remember) lets us say from 8MHz to 32MHz while other accepted only 38MHz - 40MHz (I prefer to not have such big frequency at external pins). Which pins I can use for which function (it is my task to decide when designing our devices) was complicated (each family had different restrictions on it). What references could be used for A/D converter was also not too clear for me. But generally I have to say pin flexibility is much,much higher than in AtXmega what helps in PCB design a lot (when you already know everything what you can do).

What surprises should I expect when I will start looking (from hardware point of view) at the ST32 family?

[Simon]

The simple header files are called CMSIS, and there is also LL: http://www.alexandre-boyer.fr/TP_LoPoSo/Overview_LL_Library.html
If you couldn't figure out HAL there is not much hope in you figuring out either of these though.

Don't be ridiculous. The STM HAL is one massive nightmare. It is by no means perfect and you cannot use it properly without reading the chips manual first. Or you can do what all the cool kids do these days, not read the manual, assume it's your mistake and ask online and get told: "to make it do this, do this". Then go off thinking you are all knowledgeable.

As an example. I tried setting up a PWM output with help. A value had to be entered into a box, this value was passed to a register as entered. But the MCU would interpret this value as the value + 1. Not only did the HAL not subtract 1 from the value, it did not even tell you about this. So unless you read the manual, you are clueless. Once you have read the manual you can just write your own code that is so much simpler.

I bare metal the SAMC from microcchip, much more flexible chip than STM and not that hard to get working if you want to program a MCU rather than pretending you are programming on a PC.

[Siwastaja]

I think Simon has a good example with the +1 case, very typical. The problem with ST's HAL (this is a name, not a generic term, compare to chocolate manufacturer choosing Chocolate as their brand name) is twofolds:

* Unlike actual hardware, it is completely undocumented; and,
* It is a complete separate interface, not 1:1 with hardware;

As a result, you need to learn both hardware and the STHAL, and maintain their mapping in your head, which is double the effort. Now if the HAL was excellent quality and well documented, it would theoretically be possible to learn just that, and ignore the hardware, but it fails because this is not the case, so you end up reverse-engineering the STHAL all the time.

Generic high-level abstractions work much better on general computing (e.g., think about socket interfaces instead of writing application code to a specific network adapter!) than they do on microcontrollers.

On the other hand, the HW itself (peripherals) are "properly" documented in reference manual (not perfect, and with mistakes, but at least it exists and is pretty complete documentation), so it's pretty straightforward to just open up this documentation and start writing code, and investigate/fix things when something does not work as expected. As you go, you build your own hardware abstraction layer which is exactly tailored to your needs, and which you can reuse in further projects.

Keep it simple.

[Simon]

I'm running a CAN Open master on a SAMC with 16kB of RAM despite there being a 32kB version. I wrote everything from the ground up and as a novice programmer with no experience on PC's I found it easy enough. A now ex colleague tried to use the microchip files from their HAL type system to set up the CAN bus, it took him 2 weeks to end up with something that worked. As soon as I asked him to change the baud rate it failed to produce the expected result because of one of these +1 operations in the MCU.  He was highly allergic to writing his own code or trying to understand how anything worked, he just wanted to give his orders to a library, so ever little change provoked hours of digging online. The code took much longer to compile due the sheer bloat of machine created header files that had to be parsed.

After his departure I needed to change something but I could not given this mess I had. So I spent 2 weeks reading the manual, understanding how the CAN bus controller works for what I needed, noting the ways in which I could use certain features to my advantage and I came up with my own code base that through simple function calls lets me set things up. Yes I still have to get dirty with the nuts and bolts of it when I want more functionality but that is micro controllers.

Something that people consistently fail to understand is that PC's or rather the standard C library is ubiquitous because the hardware is standardized and so an entire industry rests on the fact that the fundamentals were well thought out at the start and every consistently implements them as the only way to be in the game is to play the game. Micro controllers on the other hand are unique, they follow no standard, just standardizing across one manufacturers range is a new thing. Also micro controllers are not used in the same way as a computer, they are lower level, and the peripherals have to be very flexible so that as many people as possible can tailor them to their needs. It is pretty much impossible to write a standard interface even for one chip that allows you to use any feature at will in a way that is easy to use without getting the manual back out and rereading what your code does. I have spent 3 years trying that.

What I now do is create my electronics as part of a modular system. So I need a display in my project, great, I create a board that is just for the display, with its own MCU and it talks on CAN bus, I have a set of functions written that allow me to put text on the display as I please and in the future may add graphics. The CAN bus code is the same as other modules, so once written I reuse it even though it is code written to do things in this one way only and not try to be a jack of all trades but it will still be reused. So I need button and encoder inputs, fine, that is it's own board with it's own micro accessing the can bus using the same can code. And so a flexible system is born. You can't write the ultimate flexible HAL without making a mess, but you can create flexible hardware leveraging on the specifics of the micro that you need. So in the future when I need a button and encoder inputs I won't go wondering about what this code dose and can I use it this time because I will be designing in the context of an established system and all I need to care about is what channel number on the board did I assign to what button and so what bit will be "1" in the CAN bus message that tells me which button was pressed.

[eTobey]

HAL is a black box that may run fine, but its HUGE, and if it doesnt run smoothly, you would not have a glue about why.

These are complex microcontrollers, and anything that is in between your code and the hardware, makes it even more complex.

Here are some gotcha´s, not HAL related (this link is really worth a read, or at least saving to your favourites):
http://www.efton.sk/STM32/gotcha/index.html

[Kjelt]

For beginners: get an nucleo board, get an st.com account, login.
Then goto the STM32 Youtube MOOC and follow the course.
Expect 40 hours of studying and playing along with the board.

Then and only then start whining, the MOOC is one of the best courses as ARM microcontroller manufacturers make.
You can't expect to have 8 bit uC experience and then go directly to 32 bits and expect a sunny day scenario.
It is as knowing how to bike and then try to drive a car.

If you don't want to put it in the work, get an esp32 or stm32 duino and let other people do the work for you.

[RJSV]

   Might be helpful, to take a step back,  and for a short time,  obtain an older book, or comprehensive manual.
   The way I learned microprocessors was buying a specific book,  considered near-obsolete, but still with full explanations of the internal BUS, and block diagrams how the various registers connect.
   What is instruction 'FETCH', (?), questions like that, you should ideally have an intro.
I used the older book:
   'The Z-80'. by Rodney Zaks,  but also various other books covering the 6502,  an older, much loved IC.
   You could stare at the electrical stats, on the pin outs, all day, and still not comprehend the basics.  In your device, maybe you wish to 'transfer' the contained data, over to some other register.   You'd need to know, which instruction, in the uP set, that you should use.

   Often it might look like what's called a 'move',
   'MOV. R7, R10'

Things like that, where the instruction will copy the data from R7, and put the copy into R10.
You might have to just learn or get intro on an instruction set, by reading small portions at a time (you could ask here, if question).

   Spec. will typically list how many clock cycles it takes, to do.  Also,  notice that the example I just gave doesn't affect any outputs,  it's all internal for the one little transfer.

[RJSV]

   Linker files ?
   In my opinion that's a software abstraction,  and someone else here has mentioned C language headers.  That sounds very convoluted and distant from actual program lines.  I'm used to defining things at the top of file, but too much of that, and you get really distant from your particular device.
   I'd trust ataterov (I spelled that member wrong, sorry).  His stuff is solid, mentioned by someone earlier here.

   - - -   Rick B.
Pm ok

[RJSV]

   Info from Siwastaja reply#9 has the good info:
Please see ataradov/mcu-starter-projects

That's proper spelled now, thanks.

[Simon]

The point is that MCU peripherals are simpler than people think. My past apprentice was surprised when I showed him the few lines that it took to set a peripheral up, he seemed to think that this was all worthy of driver scale code that he had to get from somewhere and yet once you understand the peripheral it takes so little code that it is actually pointless spending even more time trying to make something like a HAL work for you.

Also if you understand the hardware properly and get clever you can do "imaginative" things that the HAL cannot do for you. So I set up the RTC on my SAMC as a general purpose time keeping counter in units of 31.5µs or 71µs. But I would have to run it off an external crystal and access to the current count requires register synchronization. Then I noticed that the CAN bus peripheral has a counter in it. OK only 16 bit not 32 bit but I don't mind an interrupt every second to keep track of rollovers and it does not require register synchronization. Well as I will always use the CAN bus and as this runs from a crystal it is very accurate and I set it up so that regardless of the CAN bus speed I use (again within limits I decided in advance for my system) it ticks at 16µs intervals. So because I took the trouble to understand the hardware I was able to use something for something it was not entirely intended but that actually works a treat. This is the name of the game with a micro controller.