There’s a tremendous amount of value in using pre-built, known-good development environments. It saves you hours of potential headaches when things aren’t working. Is the bug in the hardware or the software? If you bought a dev kit, you can be pretty sure it’s your software. But sometimes using a dev kit also feels like there’s a black box in the system. [Kevin] wanted to peer inside the black box, so he ordered a tray of cheap STM32F103 chips on eBay, and did the rest himself.
“The rest” isn’t all that much, but figuring that out is half the battle. [Kevin] soldered the TQFP chip onto a breakout board, added some decoupling capacitors, and connected four pins up to a dirt-cheap ST-Link programmer clone. The rest of the article describes the toolchain he used to compile for and program the chip. The end result is, natch, a blinking LED.
If you’re a bit experienced with microcontrollers and want to dive head-first into an ARM chip, [Kevin]’s writeup is just the ticket. In a single (long) blog post, he walks you through all the steps. If this is your first rodeo, you might be tempted to cheese out and buy a pre-built board on eBay (search “STM32F103” and you’ll find many options to choose from) and we don’t think that’s a bad idea either. Still, there’s just something to be said for the confidence that you’ll have once you’ve built the whole system from scratch.
Costwise, instead of using a breakout board, it would’ve been much better to produce your own dev board. PCB prices are dirt cheap.
My breakout board was $1 at a local shop. I can get PCBs milled (w/o soldermask or plating) at that same place for $0.07/in^2, but even at that price the cost of my time to design the board and wait for it to be printed would have been higher than the ~$0.75 difference.
Um, yeah right.
http://schmartboard.com/schmartboard-ez-qfp-32-100-pins-0-5mm-pitch-2-x-2-grid-202-0011-01/
The boards you’re using (You can clearly see the SchmartBoard logo in your pictures) cost $10 each, not $1.
I’m serious, they were selling tqfp schmartboards for $1 at the shop I go to. Honestly, I doubt they’re authentic. I was all ready to design the custom board and get it milled until I saw those.
Learning ARM With or Without Dev Board:
Embedded Systems Programming Course
https://www.youtube.com/watch?v=3V9eqvkMzHA
I just don’t feel that an instruction set simulator is the same thing as “without a dev board.” If you want to go from start to finish designing a product beyond the prototyping phase, you have to be able to know that you can just throw a microcontroller onto a PCB yourself and know that you can program it. In addition, many dev boards (such as the launchpad in the video) have a lot of extra “stuff” on them, such as a USB programmer on the board itself, that just aren’t practical for a finished product at a price point. For me, its most useful to know what I could cut out and still be able to use the dev board.
Correction “still be able to use/program the microcontroller” lol
What you did and how you described the steps is really appreciated.
The recommended video is for the people who, inspired by your story, might want to dig deeper into ARM programming. Starting with that link, there are more then 20 video workshop lessons about embedded C, ARM, debugging, common pitfalls and so on. A very high quality material.
I concur! That’s an awesome video series. His approach to learning the chip with a debugger running at the same time is great. (If those are the vids I’m thinking of…)
Kevin’s site and those videos make a fantastic pair, giving you the hardware _and_ firmware/software experiences.
Kevin:
Thanks for the post and your time to write it up.
As a developer myself, I can speak to the sometimes inaccurate simulations of a software simulator. My main choice is the ATMEL AVR8 line. I recently was working on using the SPM (self-programming) feature of the AT90USB1286. I was finally able to get my code working properly in the software simulator and then switched to real hardware. Oops! It no longer works. My point is … all is not as it seems in simulation land. Always test your code on the real hardware.
Also, I’ve seen this going on for too long now and I am strongly compelled to finally post it. I can’t help but get so turned away at some of the responses that some people post on HACKADAY. Sometimes, they are so very negative, abusive and belittling. I know I am painting a target on my virtual(ly anonymous) self (so you all can’t hunt me down and hurt me for saying so). You folks that make those derogatory posts looking to poke holes, (sarcastic = intentionally hurtful) fun or start an argument with the poster, why do you feel the STRONG NEED to do that? Are your egos so fragile and insecure that you fond that necessary? Please lighten up a bit. If you have an ax to grind on the world and all its inhabitants, go find an ax and a grinder and grind away to your heart’s content but stop attacking people just because you NEED to and can do it anonymously. The acts certainly do not help on a even a limited level at bringing about love, peace harmony and global prosperity to our global society. We are all in this together.
P.S. Any derogatory comments to this post will be rightfully (and leftfully) ignored.
Peace and blessings,
Johnny Quest (and Bandit)
Excellent, thanks!
Which ARM vendor would you suggest for a hobbyist? I’ve toyed around with STM32 a few years ago. The ST libraries seemed a bit awkward at that time. Any suggestions? NXP, atmel, ….?
So, I actually started out with Freescale/NXP because of the Teensy 3.1. I tried to do this exact project with the Freescale Kinetis series using a KL26 and pretty much failed because I had to build the programmer for it (the actual programmer is $200 minimum). I used my Raspberry Pi to bitbang the SWD interface actually got to the point of programming a KE08 microcontroller, but I could never get it to work for my KL26’s (it always reported that the device was locked). So sad. Freescale/NXP has good libraries, if you can find them for the specific processor you’re using (they tend to be easier to find if you use a processor from one of their dev boards). For dev boards, however, The Kinetis FRDM boards are really nice and the Teensy 3.1/2/LC are also quite cost effective. They have the best value IMO with bang-for-buck…if you can manage to get them programmed.
STM32’s are significantly easier to program IMO and their libraries are easier to locate. I’ve heard their HAL library is garbage, but I haven’t tried it out personally and I tend to not bother with those anyway. The header files and stuff are significantly easier to find than the ones for Freescale since they have this “STM32Cube” software product for every one of their STM32s. The programmer is also cheaper, so you don’t have to spend a year off-and-on programming your RasPi to be a programmer.
I haven’t tried the Atmel ARM offerings, but I have had great success with AVRs in the past (and I still use them today because they’re so easy). I would imagine that libraries and documentation are quite good, but I haven’t looked in to programmers and that could really be the kicker.
From doing this project I think the thing to focus on for getting started quickly is “how easy is it to flash the microcontroller?” If there is no cheap programmer available, you’re going to have to build one and that could be a very arduous process. The other half, writing the software, is almost universal: Grab the documentation, use arm-gcc (write your own linker script if needed) and run with it. If it really came down to it, you could use the reference manual and write your own header file. But, if you can’t even flash the microcontroller as a hobbyist then it doesn’t matter how awesome the software libraries are.
Seriously, I got this STM32 stuff up and running in like 3 hours after receiving all the parts. The advantage of STM32 is that since its been around so long, STLink clones are really easy to find. As the other microcontroller lines gain age and experience, I imagine something similar could happen for NXP, etc. Go with the STM32 to start and then branch out from there.
Correction: It was a KE04 that I programmed in the Freescale Kinetis series. There’s no such thing as a KE08 lol
Hi Kevin,
Looks like you have locked the protection bits in the Flash Configuration Field, and the Flash now needs to be mass-erased. Be careful/avoid writing the 16 bytes starting at 0x400 in Flash.
I use a PE Multilink, which indeed is quite expensive, but a cheap FT2232 will work with OpenOCD, esp. for KL26 which is available on a Freedom board (FRDM-KL26). Of course, you can also use the OpenSWD programmer on the Freedom board to program an MCU on your custom PCB.
For K-series Kinetis devices, in addition to JTAG/SWD you have the EzPort, which is essentially an SPI slave. See the Freescale/NXP appnote AN4406.
* of course s/OpenSWD/OpenSDA/
Also, some new K-series MCUs now have a ROM bootloader.
I actually had never even got to flashing the 0x400 configuration field. I worked on this project for about a year and a half before giving up and switching to the STM32s. I’d love to get it working though. The KL26’s had lucrative power consumption figures and is the cheapest ARM on digikey with a USB module.
So, here is the sequence of events that I would see off of a factory-fresh chip, soldered to my dev board with my hot air gun. I have a python program that does the following by bitbanging the RasPi GPIOs:
1. Connect via SWD, read IDCODE, if it looks good, continue.
2. Read MDM-AP. It reports flash ready, security is set, mass erase is enabled.
3. Write MDM-AP. I only set bit 0, which should trigger mass erase.
4. Read MDM-AP repeatedly. Bit 0 is always set and remains that way (I’ve had it go for like 5 minutes). This tells me that mass erase never actually began.
My suspicions are any of the following:
– I’m performing the mass-erase sequence wrong. I think this could mainly be the issue, but the weirdest thing to me is that the device is reporting that it is secured straight out of the box. That just seems wrong.
– The jittery RasPi GPIOs caused some sort of malfunction
– I forgot to tie a pin somewhere and the flash module isn’t initializing correctly (I’m not sure which one, if any). The flash ready bit in MDM-AP is actually not always set, so perhaps I did something wrong there.
– I somehow damaged 4 chips in a row when soldering them. I’m unsure if this could be the case…the reset pin shows the correct ramping pattern for an unprogrammed device.
Anyways, I do have an FRDM (KL25), but the issue with those is that you can only program the exact same chip which is found on the board itself. I could by a KL26 FRDM and use that of course, but it would be nice to get my SWD programmer working. I mainly targeted the KL26 because of its cheapness and the fact that it had a USB module. Sadly, none of this family come with an EzPort as far as I know. I was actually really excited about that when I read about it in the K20 reference manual for my Teensy 3.1 (its got a MK20DX256VLH7). I’ve only seen that on the slightly more expensive K-series so far, but I haven’t looked to deeply at any other families to be honest. I’ll probably look deeper into the ROM bootloader; that could be another viable option.
If you’re already using the ST-LinkV2 as an SWD programmer with openocd, can’t you connect that to the KL26 and point openocd at a KL26 config file? Or is there some sort of incompatibility? I know I’ve used openocd + the STLinkV2 off a Discovery board with other brands of MCU before, but I don’t know about the KL26. Maybe if you try a slower speed?
If you have a FRDM-KL25Z board, mbed have a much better replacement firmware for the OpenSDA chip on the FRDM-KL25Z board than that P&E stuff it comes with: https://developer.mbed.org/handbook/Firmware-FRDM-KL25Z . It enumerates with a few interfaces. The drag-and-drop mass-storage based flasher will only work with KL25Zs, but it also presents a CMSIS-SWD interface. Combined with openocd, that should work with any SWD-capable Cortex-M chip you’d like, including KL26Zs and your STM32s too.
There’s also a SEGGER J-Link Lite firmware available for free download on SEGGER’s site for the OpenSDA: https://www.segger.com/opensda.html . It’s locked to Kinetis chips, but I think it allows you to target other Kinetis chips, not only the KL25Z. The J-Link firmware can work with openocd, or you can use SEGGER’s tools from their site. Their tools might have the highest chances of success clearing the protection: https://mcuoneclipse.com/2014/10/05/unlocking-and-erasing-flash-with-segger-j-link/
You don’t even need an STLink clone to flash the STM32F103 – the ROM bootloader speaks serial. (Though it probably comes in handy for debugging.)
You need some “environment” that makes things that should be easy, easy. I tried libopencm3, and it didn’t help. Some things that shoul’ve been easy were not.
I’m now using chibios. At least it has all the registers defined in a usable way. When worst comes to worst, you can drive the hardware yourself. (if for example a driver does not do what you want.).
Still some things that I think should be easy, are not. For example, if you have a simple application that blinks a led it should be easy to “port” that from one board to another. The official recommendation is to start over with a demo project for the other processor.
As I understand it, and I could be very wrong, is that ARM sets the basic requirements for an ARM family, and each licensee is free to implement the peripherals there own way. Which makes it easy to move up or down the chain within a licensees line, but difficult to laterally move to the same level of competitors.
You understand correctly. In fact, the core, the part that is similar, is the one that is best abstracted by the compiler. Peripherals differ between devices and manufacturers a lot. You could say switching between 2 similar ARM chips can be as different as switching PIC/AVR.
I think STM is still the best bet. Their official dev boards cost like 10€ and include a good, widely supported STLINK programmer. Their libraries aren’t that great – mostly because they really only offer bare bones stuff (I am talking about their older – pre Cube libraries). But they get the job done. The official examples are pretty useful and do the job and are pretty easy to understand.
Get yourself the great http://www.emblocks.org IDE that has very easy to use project generator and everything and supports most of the STM32 boards out of the box.
If you need something like BLE then I recommend Nordic nrf51 series. Nordics libraries are much more powerful than STMs. They offer things like multitasking, common timing functionallity, … out of the box. And their chips can be configured with pretty much any function on any GPIO pin. Sadly you need something like ARM Keil to get good out-of-the-box experience. And their dev boards are more expensive. I made my own boards for that reason. But I still use my ST dev boards to program the nordic chips.
+1
ST supports Contiki, and cubeMX can be used to setup FreeRTOS.
Im not a big cube fan, but for setting up and blinking an LED, etc., its really, really easy.