I’ve been using the STM32F205 / STM32F405 Cortex-M4 on a recent project and, in general, enjoying the capabilities, performance and low cost of the part. However I haven’t been too excited about the documentation provided by ST, nor by the quality of the ST-supplied example code. As I’ve been finding code bugs, undocumented chip errata, etc, I’ve been posting them over at my blog. It’s getting to the point where there are enough blog postings to warrant this webpage simply to organise them all.
The blog postings apply to all devices in the STM32F2xx and STM32F4xx family. This includes the STM32F205, STM32F207, STM32F405 and STM32F407.
This blog posting gives a brief general overview of a couple of topics, in particular making note that if you have problems with the STM32 discussion forum or tech support webpages, you’re not alone. Along with some helpful tips.
STM32F2xx and STM32F4xx DMA Controllers
The DMA controllers on the STM32 processors can be quite confusing to the new (and not so new) user. It comes up a lot on the forum. A big part of the problem is the incomplete documentation from ST.
There are two blog posts on the STM32 DMA controllers. Post 1 is here, and post 2 is here. If you’re going to be using the DMA controllers for anything beyond an exact copy of some ST example code, I strongly suggest you read these posts. They will help you understand why your DMA transfer works the first time but not the second time, why you’re getting an interrupt when you turn off the DMA controller (and what you can do to prevent that), why some DMA registers seem to change values but others don’t, and so forth.
In addition, be careful with simultaneous DMA transfers. Make sure you have no more than 2 DMA transfers running at any one time. More than 2 can apparently cause problems – see this posting.
STM32F DCMI Digital Camera Interface Port
In my opinion, this port is the “jewel in the crown” of the STM32F2xx / STM32F4xx parts. I don’t know of any other cortex-m3 or cortex-m4 processor which has a camera interface port like this. If you’re not careful it can do strange things at times, like unexpectedly skipping frames. If you’re going to be using the ST DCMI port, I suggest you read this post.
STM32F SDIO SD Card Interface
The STM32F205 / 405 etc parts have a true 4-bit SD card interface. It actually works pretty well once you get it going. In benchmark tests I’ve managed to write to cards at up to 9 MB/s, which is quite impressive for a microcontroller. The big problem with this port is the relatively poor quality of the ST supplied SD example code. ST provides some “library” code to do things like read and write blocks of data to the card, and also provides simple examples showing how to use those functions. Those examples generally work because they’re small and quick. In “real world” applications when you’re trying to write complete files to a card for example, you typically start seeing many strange errors.
This blog post should help you find some of those problems. Unfortunately you cannot treat the ST supplied code as a drop-in “black box”; it’s too buggy for that. You need to treat it as example code, as a starting point for your own SD code. There’s no avoiding reading the SD card specification, which you can download for free from here (the physical layer simplified spec is most likely the one you want). With the spec in one hand and the ST code in your other, you have a great start on getting that STM32F SD card interface working reliably.
In addition, if you plan to use the SDIO port under interrupt (for data handling instead of DMA) then you should also read this post.
If you think your write speed is slower than it should be, this post might also be of help.
If you need a filesystem on the card, I use and highly recommend the free Chan FatFS library. It’s easy to port (you only need to edit one file), easy to use, and I haven’t found any problems with it.
Cortex M3 M4 Hard Fault Handler
If you’re getting a hard fault error and can’t make sense of it, or if you want to install a hard fault handler “just in case”, have a read of this post.
A Couple of Common Trip-Ups
These two things come up time and again on the forum for new STM32 users.
Peripheral Doesn’t Work
Usually because that peripheral’s clock hasn’t been turned on. By default (after reset) the clock for almost all peripherals is off, to save power. Before you can use a peripheral you need to enable its clock, using the RCC_AHB1PeriphClockCmd() function (or similar).
Interrupt Happens Twice or Repeatedly
Usually because the interrupt is being cleared at the bottom of the interrupt service routine, instead of at the top. The Cortex-M3/M4 is a pipelined processor – things can take a few cycles to propagate their way through the chip. If you clear the interrupt at the end of the interrupt service routine, it might not have cleared from the NVIC by the time the service routine exits, resulting in the interrupt re-triggering.
The STM32F forum can be found here (although it does move from time to time, so search around if this link is broken). I have given a number of postings on that forum; try this link if you want to look for them. There is also a sub-forum specific to the STM32F4 Discovery board that might be of interest.
STM32F2xx / STM32F4xx Consulting Assistance
If you’re starting off a STM32F2xx or STM32F4xx project and you want some help with software, hardware (schematics or PCB layout), etc, feel free to contact me through this website. I am quite limited in the time I have available so if you need someone to do your entire project for you, I’m not the right person. But if you need some specific help with some portion of your project, or just help getting started, feel free to drop me an email and we can work something out.