Skip to main content

STM32 Documents Every Programmer Needs.

I dedicate this post to anyone on YouTube who has ever asked me to send them the datasheet or reference manual. Please make an effort and Google it , I promise you will find it. But if you dont then here they are.

As the years pass I notice STMicroelectronics has changed how they handle the documentation for their products. For example in the older STM32F1 series reference manual (RM)  there is no talk about the FLASH registers and instead the RM tells you to seek out the Programmers Manual (PM). While the new G0 series has the FLASH registers fully documented in its RM.

So here is a list of documentation every STM programmer should have.

The Reference Manual

Denoted as RMxxxx where x is some number, for example STM32F1 is RM0008 This is by far the most important document in your arsenal and the one you will visit the most. It defines all peripheral registers as well as their respective bits. The RM also highlights different operation modes for your device and its peripherals.  Provides an overview of the system architecture and gives you  an overview of the memory map. If for some reason you where writing and defining each register by hand instead of using the vendor header files this document would be your friend since it provides the address and offsets for all your peripherals. It also provides the reset values for all these registers, sometimes however that must be taken with a grain of salt and its best to reset registers to a known value yourself. Also some newer RM like the L0 have actual C code that does basic programming of ALL the peripherals, so no more googling how to setup UART its all in the manual just copy and paste the code. They will make my blog obsolete :(

The Programmers Manual

This document can come in 2 flavors and is often called "Programming Manual" For example for the STM32F1 the PM0056 is the Cortex-M3 Programming Manual and PM0068 is the Flash Programming Manual. Truth be told you need them both! 

The M3 Manual will provide you with the following:

  • Memory Model
  • Exception Model
  • Fault handling
  • Power Management
  • Instruction Set
  • Core Peripherals:
    • Memory Protection Unit (MPU)
    • Nested vectored interrupt controller (NVIC)
    • System control block (SCB)
    • SysTick timer (STK)

The Flash programming manual will provide you with the following:

  • Read operation description
  • Flash Program and Erase Controller (FPEC)
  • Protections schemes for read and write
  • Option byte descriptions
  • Complete FLASH registers description

The Datasheet

The reference manual is often called the datasheet but in STM's naming convention they are two different documents. The datasheet is 118 pages while the reference manual is 1132 , so yes.. two very different documents. The datasheet offers a highlight of the products features and capabilities. This document is helpful when designing a PCB that uses the specific microcontroller. It gives recommended layout for things like NRST pin , ADC pins etc...

Datasheet provides the following:

  • General description, operating voltage, temp max and use cases
  • Device overview covering available peripherals in different packages/pin outs
  • Compatibility references among products of the same family
  • Pin out and pin descriptions
  • Memory Map , more detailed. 
  • Electrical Characteristics
  • Package information, for modeling PCB footprints
  • Full breakdown the part number naming conventions

HAL and LL driver API Manual

For example document UM1850 describes CUBE HAL as well as LL drivers for the STM32F1 , this is your go to document to figure out what functions are available in your abstraction layer of choice. It gives a detailed overview of the functions and available accepted  parameters to those functions in the form of defines or typedefs etc...

Hardware Design Reference

This is a good document to have if you are eventually going to turn your bluepill into a standalone design with its own PCB, link here. This document as the name implies gives some details about how to connect an external clock source, how to connect the boot pins , reset, jtag etc...

Evaluation Board Schematics

If you are using a Nucleo or Discovery board you obviously need the schematics for it.It shows you what pins the buttons are tied to. Are the LEDs active high or low? What are all the solder bridges for?  etc... Cant link it for the F1 because it is a zip file. 

The last document you need is a good resume because you'll one day a microcontroller programming master! 


Popular posts from this blog

Interface a Rotary Encoder the right way.

So whilst reading my favorite odyssey found here I stumbled onto something I never spotted before. It turns out that the general purpose timers support hardware interfacing with an incremental encoder. This means no more interrupts and no need to increment whatever variable you had. Now all you have to do is get the value from the Count register in the timer. Did I also mention it takes care of figuring out which direction you are turning it? Amazing! Lets talk about it.

Encoder Interface Mode Verbatim from the reference manual of the STM32F103 page 392 or Section 15.3.12  "Encoder interface mode acts simply as an external clock with direction selection. This 
means that the counter just counts continuously between 0 and the auto-reload value in the 
TIMx_ARR register (0 to ARR or ARR down to 0 depending on the direction). So the user 
must configure TIMx_ARR before starting. In the same way, the capture, compare, 
prescaler, trigger output features continue to work as normal."

STM32L0/F0/F3 I2C : Part 3 RX TX via DMA

Most modern microcontroller come with a peripheral called DMA which allows for an even more hands-off approach. The Direct Memory Access controller will get a tutorial of it's own in the future. However, it is so simple to use that I can easily explain the required bits in this tutorial without feeling like I will overwhelm the reader. In this iteration of the I2C series I will cover how to TX and RX date on the peripheral in conjunction with the DMA controller. 

First let me briefly explain in a high level what the DMA controller does. It allows you to transfer data in 3 ways: Peripheral to memoryMemory to peripheralMemory to memory. What does this mean? For example, when you receive data on I2C in your RXDR register, you can have the DMA controller move that data received into an array. At the end of the day your variables are just memory locations, so if you have declared an array it has an address associated with it, this is address is what the DMA considers  "Memory"…

STM32 I2C Does it suck?

Recently I have been annoyed with  bugs in the I2C implementation in ST's F1/L1/F40/F2 series, and  any microcontroller made by ST before 2012. There appears to be, what I can only describe as, a race condition when attempting to receive data in I2C interrupt(low priority)  or polling mode.

Just to be clear a race condition is defined as , verbatim from wiki: "the behavior of an electronics, software, or other system where the system's substantive behavior is dependent on the sequence or timing of other uncontrollable events. It becomes a bug when one or more of the possible behaviors is undesirable."
I was humming along trying to make my YouTube tutorials when I arrived to the I2C protocol implementation. I have used I2C with the F1 series plenty of times, however I have never had the need to receive data from a slave. However for the sake of completeness I decided to implement an RXing routine in I2C for my tutorial. Only to find statements like this in the referen…