I have a bit of a love/hate relationship with the Arduino. But if I had two serious gripes about the original offering it was the 8-bit CPU and the lack of proper debugging support. Now there’s plenty of 32-bit support in the Arduino IDE, so that takes care of the first big issue. Taking care of having a real debugger, though, is a bit trickier. I recently set out to use one of the cheap “blue pill” STM32 ARM boards. These are available for just a few bucks from the usual Chinese sources. I picked mine up for about $6 because I wanted it in a week instead of a month. That’s still pretty inexpensive. The chip has a lot of great debugging features. Can we unlock them? You can, if you have the right approach.

The Part

For a few bucks, you can’t complain about the hardware. The STM32F103C8T6 onboard is a Cortex-M3 processor that runs at 72 MHz. There’s 64K of flash and 20K of RAM. There’s a mini-USB that can act as a programming port (but not at first). There’s also many 5 V-tolerant pins, even though this a 3.3 V part.

You can find a lot more information on this wiki. The board is a clone–more or less–of a Maple Mini. In fact, that’s one way you can use these. You can use the serial or ST-Link port to program the Maple bootloader (all open source) and use it like a Maple. That is, you can program it via the USB cable.

From my point of view, though, I don’t want to try to debugging over the serial port and if I have the ST-Link port already set up, I don’t care about a bootloader. You can get hardware that acts as a USB to ST-Link device inexpensively, but I happen to have an STM32VLDISCOVER board hanging around. Most of the STM32 demo boards have an ST-Link programmer onboard that is made to use without the original target hardware. On some of the older boards, you had to cut traces, but most of the new ones just have two jumpers you remove when you want to use the programmer to drive another device.

The “blue pill” designation is just a common nickname referring to the Matrix, not the pharmaceuticals you see on TV ads. The board has four pins at one edge to accommodate the ST-Link interface. The pin ordering didn’t match up with the four pins on the STM32VLDISCOVER, so you can’t just use a straight four-pin cable. You also need to bring power over to the board since it will have to power the programmer, too. I took the power from the STM32VLDISCOVER board (which is getting its power from USB) and jumpered it to my breadboard since that was handy.

The Plan

Programming the board is easy — I knew the community had done a lot of work to create a support package for it. You do need a recent version of the Arduino IDE (not the one that shows up in the default Ubuntu repositories). I downloaded version 1.8.1 from the Arduino website, just to be sure. That was the first step of my general plan of attack:

1. Load the latest Arduino IDE
2. Set the compile messages to verbose
3. Use the Board Manager to install the STM32 F1 packages
4. Get more tools
5. Capture the build directory
6. Run the right version of GDB

The recent versions of the Arduino IDE let you select platforms by using the Board Manager (available from the Tools | Board menu). However, if you look, you won’t see this board on the list. You’ll need to tell the IDE where to get the third-party support package. To do that, you can go to the Preferences menu item (on the File menu for Windows and Linux; I understand it is on the Arduino menu on the Mac). You need this same preferences dialog for step two, also.

Step 2 isn’t strictly necessary, but it will make step 5 easier. Just check “Show verbose output during compilation.” What you really need to know is the temporary directory the IDE uses for your build and this is the easiest way to do that, as you’ll see.

Further down the preferences screen is an entry for “Additional Boards Manager URLs.” If there’s already something there you should click the little button to edit the list. If it is empty, you can add this URL:

https://github.com/stm32duino/BoardManagerFiles/raw/master/STM32/package_stm_index.json

Now you can go back to the Tools | Board menu, pick Board Manager, and search for STM. You’ll probably see a few packages (I had three) but the one for the F1 will specifically mention the blue pill. Click the button to install and wait for it to do its thing.

Once installed, you’ll have some new entries on your board menu. When you have the blue pill selected, you’ll be able to pick a few options for uploading including the one we want: ST-Link.

Coding

The package has all the stuff you need to build and download programs using a variety of methods, including ST-Link. However, it doesn’t have the particular tool you need to do debugging.

It is simple enough to build the tools. The GitHub repo has the code and some simple build instructions. You do need libusb and CMake, but the page explains all that and once you have all the pieces, the build goes fast. For many OS choices, there are pre-built binaries you can use, too.

You’ll also need to know the USB ID of your ST-Link board and add it to the udev rules for Linux. If you don’t do this, you’ll need to be root to program the device and that’s not a good idea. However, depending on which ST-Link interface you use, it may already be there from other software or from the Arduino install. I’d try a test first and if it only works as root, you’ll need to update udev.

If you did your own build, I suggest running the tool stlink-gui to perform the test. You can also run st-info --descr

If you run stlink-gui, press the connect button with the ST-Link and blue pill powered up and connected. You should get the information about the device. If not, try as root. If that works, you need to update udev. I created a file, /etc/udev/rules.d/45-stlink.rules.

ACTION=="add" SUBSYSTEM=="usb", ATTR(idVendor)=="0483", 
     ATTR(idproduct)=="3744", MODE="0666", GROUP="usbusers"

You’ll need to modify that for the USB ID of your particular interface (mine was 0483:3744; the lsusb command can help). The mode allows all users to read and write the device. I made the group owner usbusers, but since everyone can access the device that probably isn’t strictly necessary.

Once you can do all that, try running the blink sketch from the IDE examples. Be sure to pick “Upload Method: STLink” from the Tools menu of the Arduino IDE. If it doesn’t work, you may need to use the tools you just built instead of the ones that come with the Arduino IDE. Mine worked but the debugging required the custom build (because the Arduino package didn’t ship with that particular tool built).

Finding the Tools and Build Directory

The Arduino IDE is pretty friendly, so it doesn’t try to install things like boards for all users, since that would require root. The board package you loaded winds up in your home directory under ~/.arduino15/packages/STM32/tools. There’s an STM32Tools directory and a few more levels down you’ll find copies of the ST-Link tools. If they don’t work, you can manually run the tools you built in the previous step to do your uploads. When we debug, we are going to do that anyway.

What’s really important though is back under the STM32/tools directory is another directory with the compiler that the IDE uses to compile your code. There’s also a matching version of GDB — the GNU Debugger — there that you will have to use.

If you loaded an example, make sure you save it to your own directory (I hate saying sketchbook). If you don’t, the IDE will make a private copy of any changes you make and things will get confusing.

Do a build (the checkmark icon) and — assuming you checked the box in step 2 — you’ll get a lot of output from the build tools. You might verify that the compiler in use is the one we mentioned above. You’ll also see that your program gets added to other things and put in a directory named something like /tmp/arduino_build_XXXXXX where the XXXXXX is a number. Your source code will be in this directory named something like sketch/Blink.ino. In the top-level directory will be the executable Blink.ino.elf. This is what you need to debug.

If you are comfortable editing your Arduino settings file (just be sure the IDE isn’t running first) you can also force a build directory using the build.path key. The IDE does have an “export binary” command (on the Sketch menu) that compiles to your sketch folder. However, this .bin file doesn’t have enough information for the debugger.

Debugging at Last

Finally, you can debug. Use the arm-none-eabi-gdb executable from the same directory as the GCC used to compile your program. This is important. If the versions don’t match you’ll get strange errors even though many things will seem to work. Provide the name of the elf file as an argument to GDB.

If you like, you can use the -tui flag to GDB to get a sort of text-based GUI. Either way, you have one more step to go. The st-util tool you built earlier can listen to the ST-Link interface and provides a socket that GDB can use to do debugging.

Start it like this:

st-util -p 1234

That will make it listen on port 1234. If you already use that port for something else, pick another one. Just remember that on Linux only root can listen on ports below 1024, so pick a bigger number.

Once that is running, you fire up GDB with your elf file name and issue the command:

target extended-remote :1234

Or, I’ve recently started using:

target remote :1234

You can run the two parts on different computers, so use a hostname if necessary (that is, devbox21:1234). Most times, the programs are on the same box and you can use localhost or omit it like I did. The difference between remote and extended-remote is that the server does not shut itself down at the end of an extended-remote session. It often works, but I have seen cases where I had to restart the server anyway, so lately I’ve been using plain-old remote to force me to restart it with each session.

A “load” command to GDB will now flash your program to the board. A typical session after a load might be:

break main
continue
list
n
n
n

The “n” command steps to the next instruction.You can find a lot more about using GDB in an earlier post. You also might find it easier to watch the walkthrough in this video:

A few caveats. First, optimization can cause your lines to execute out of order, or even go backwards. It can also cause variables to not be visible where they have been optimized out. The other thing to watch out for is that, in some cases, the debugger internally single steps. This can cause very slow execution of delay routines, for instance. You might reduce or remove delays while debugging or be careful where you try to single step instead of placing breakpoints.

Final Thoughts

It would be neat if the Arduino IDE let you debug inside of it. However, there are ways to do that using Eclipse (and GDB) or Visual Studio (if you use Windows). If you are like me and OK with the command line, you might think about using one of the Makefiles for Arduino instead of the IDE. If you aren’t OK with the command line, there are GUI shells for GDB that you could try. If you’d rather hack the ST-Link firmware, we’ve seen that done, too. If you miss doing printf’s, you might want to try a Black Magic probe, which ought to work about the same as the ST-Link interface, but also provides a serial port for printf and other mischief.

By the way, Arduino isn’t the only choice for this board. It is possible to use mBed and other development tools with them. But that’s a topic for a future post.

2016 was a great year for Open Hardware. The Open Source Hardware Association released their certification program, and late in the year, a few silicon wizards met in Mountain View to show off the latest happenings in the RISC-V instruction set architecture.

The RISC-V ISA is completely unlike any other computer architecture. Nearly every other chip you’ll find out there, from the 8051s in embedded controllers, 6502s found in millions of toys, to AVR, PIC, and whatever Intel is working on are closed-source designs. You cannot study these chips, you cannot manufacture these chips, and if you want to use one of these chips, your list of suppliers is dependent on who has a licensing agreement with who.

We’ve seen a lot of RISC-V stuff in recent months, from OnChip’s Open-V, and now the HiFive 1 from SiFive. The folks at SiFive offered to give me a look at the HiFive 1, so here it is, the first hands-on with the first Open Hardware microcontroller.

Before I dig into this, I must discuss the openness of the HiFive 1, and RISC-V in general. Free Software and Open Hardware is a religion, and it’s significantly more difficult to produce Open Hardware than Free Software. No matter how good or how Open the design is, the production of the first Open Source microcontroller will generate far too many comments from people who use the words ‘moral imperative’ while citing utilitarian examples of why Open and Libre is good. You should ignore these comments, but not just because these people have only read the back cover of the Cliff’s Notes for Philosophy For Dummies.

The Openness of the HiFive 1 and RISC-V

The biggest selling point for RISC-V chips is that there are no licensing fees, and this microcontroller is Open Source. This is huge — your AVRs, PICs, ARMs, and every other microcontroller on the planet is closed hardware. You can’t study the silicon. If we’re ever going to get a completely Open Source computer, it has to start somewhere, and here it is.

With that said, this is an Arduino-compatible board with an FTDI chip providing the USB to serial conversion. If we had a facepalm emoji, we’d use it here. An FTDI chip is not Open Source, and they have designed drivers to break chips that aren’t theirs. The design files for the HiFive 1 were made with Altium, a proprietary and non-Free software.

Will Stallman ever say the HiFive 1 is Free as in speech? Absolutely not. Instead, the HiFive 1 is an incrementally more Free microcontroller compared to a PIC, ARM, or AVR. There will be people who will argue – over the Internet, using late-model Intel processors with Management Engines — this is insufficient to be called Free and Open Source. To them, I will simply link to the Nirvana fallacy and ask them to point me to a microcontroller that is more Free and Open Source. Let’s not cut down the idea of an Open Source microcontroller because it’s not perfect on the first release.

Hardware Teardown

So, what’s in the HiFive 1? The spec sheet is simple enough, the datasheet is complete enough,  although there are some caveats:

• Microcontroller: SiFive Freedom E310 (FE310)
  • CPU: SiFive E31 CPU
  • Architecture: 32-bit RV32IMAC
  • Speed: 320+ MHz (the stock frequency seems to be about 256 MHz, this can be changed)
  • Performance: 1.61 DMIPs/MHz
  • Memory: 16 KB Instruction Cache, 16 KB Data Scratchpad
  • Other Features: Hardware Multiply/Divide, Debug Module, Flexible Clock Generation with on-chip oscillators and PLLs
• Operating Voltage: 3.3 V and 1.8 V
• Input Voltage: 5 V USB or 7-12 VDC Jack
• IO Voltages: Both 3.3 V or 5 V supported
• Digital I/O Pins: 19
• PWM Pins: 9
• SPI Controllers/HW CS Pins: 1/3
• External Interrupt Pins: 19
• External Wakeup Pins: 1
• Flash Memory: 128 Mbit Off-Chip (ISSI SPI Flash)
• Host Interface (microUSB): Program, Debug, and Serial Communication

Basically, the HiFive 1 is the SiFive FE310 microcontroller packaged in an Arduino Uno form factor. The pin spacing is just as stupid as it’s always been, and there is support for a few Adafruit shields sitting around in the SDK.

There are no analog pins, but there are two more PWM pins compared to the standard Arduino chip. The Arduino Uno and Leonardo have 32 kilobytes of Flash, while the HiFive 1 has sixteen Megabytes of Flash on an external SOIC chip.

The HiFive 1 supports 3.3 and 5V I/O, thanks to three voltage level translators. The support for 5V logic is huge in my opinion — nearly every dev board manufacturer has already written off 5V I/O as a victim of technological progress. The HiFive doesn’t, even though the FE310 microcontroller is itself only 3.3V tolerant. It should be noted the addition of the voltage level translators add at least a dollar or two to the BOM, and double that to the final cost of the board. It’s a nice touch, but there’s room for cost cutting here.

Other than that, the only other chip of note on the board is the FTDI FT2232HL, a well-supported but most certainly not Free and Open Source USB to UART chip. This is a two-port chip that provides programming, serial, and debug connections simultaneously.

Getting Started With The HiFive 1

The folks at SiFive realize documentation and SDKs are necessary to turn a chip into a development board. To that end, they have a bare-metal SDK and support for the Arduino IDE. The board itself comes with a bootloader, and when you plug the HiFive 1 into a USB you get the equivalent of the Blink sketch from the Arduino. Yes, you too can have Open Source blinkies. What a magical time to be alive.

Right now there are two methods of programming the HiFive 1. The Freedom E SDK, and the Arduino IDE. The Arduino IDE appears to be dependent on the Freedom E SDK, so either way, you’ll have to get the SDK running.

Right now, the SDK only works under Linux (and OS X, and possibly Cygwin), but support for Windows is coming. For Linux users, the getting started guide is more than sufficient, although it will take quite a while (at least 30 minutes) to build all the tools.

Once the Freedom E SDK is installed, support for the Arduino IDE pretty much falls into place. You’ll have to futz around with the Boards Manager, but with a few clicks, you get something fantastic. You can blink an LED with Open Source Hardware.

 Actually Programming the Thing

Blinking an LED is proof enough this can be programmed, but what about the vast SDK we had to install before getting the Arduino IDE working? Here, too, it’s pretty easy to get the SDK up and running:

For this example, I simply changed the ‘hello world’ program shipped with the SDK to a ‘hello Hackaday’ program, compiled it, and ran it. Yes, someone as dumb as me can compile and upload a program to the HiFive 1.

This Stuff is Still New, Okay?

Before receiving the HiFive 1, I originally planned to benchmark this dev board against other small, common dev boards. The SDK comes with a Dhrystone program, making this the obvious choice. The results were not good, but this isn’t a reflection of the power of the FE310 microcontroller. Allow me to present the shocking infographic you should not pay attention to:

This test used this Dhrystone Arduino sketch with the Arduino Micro, HiFive 1, and the Teensy 3.6. As you would expect the Arduino Micro performed poorly (but still ten times faster than a mainframe from 1988), and the Teensy 3.6 was extremely fast. According to this benchmark, the HiFive 1 did terribly at barely twice the computing power of the Arduino while running 16 times faster. If this benchmark was accurate, it would immediately spell the end of the RISC-V ISA.

The above benchmark is not accurate, and the poor Dhrystone performance was due to incorrect assumptions about the timer’s frequency. I plopped this problem up on the SiFive forums, and a patch was available in a few hours. What does the real benchmark say?

I love this test. Beginning this review, I originally planned to run a few benchmarks on an Arduino, a Teensy, and the HiFive 1, throw together a graph and spend a hundred or so words on the results.  I got so much more.

Right off the bat, we can see the HiFive 1 is fast. Really, really fast. Right now, if you want to build a huge RGB LED display, you have one good option: the Teensy 3.6. If you need a microcontroller to pump a lot of data out, the Teensy has the power, the memory, and the libraries to do it easily. In this small but very demanding use case, the HiFive 1 might be better. The HiFive 1 has more Flash (although it’s an SPI Flash), it has DMA, and it has roughly twice the processing power as the Teensy 3.6. This could be very, very cool, and I can’t wait to see the real life examples of how much the HiFive 1 can push out of its pins.

There’s your hundred word review on the performance of the HiFive 1 based on synthetic benchmarks. However, getting this benchmark working revealed far more about the state of the HiFive’s software, and how much support SiFive is throwing at it.

Admittedly, I do have a very early version of this board, and the CrowdSupply campaign for the HiFive 1 was only funded last week. No one would expect one of the three demo apps shipped with a newly released board with a mature architecture to be completely broken (unless it’s an Allwinner chip, but whatever). Very few people would expect the devs to get a patch out in less than 24 hours in response to a random person on a support forum.

All of this circles back to a single observation on the HiFive 1: It’s new. The HiFive 1 and all RISC-V microcontrollers don’t have a vast market share, user base, or decades of work behind them. However, the SiFive team seems to be taking their work seriously. They’re fixing the problems they have, and they’re constantly pushing out new documentation. This is great, and a very good indication of how much support the RISC-V chips from SiFive will have.

Chips As A Service

I should note that the folks at SiFive aren’t in the business of building RISC-V Arduino boards. They’re in the business of making chips for people. This is custom silicon we’re talking about here.

The easiest parallel to draw is between SiFive and OSH Park. These companies don’t have their own manufacturing capability; the value is in connecting end users (engineers, startups) to manufacturers. OSH Park connects you to a board house that really knows purple, and SiFive connects you to a chip fab. In the case of the FE310, that’s TSMC.

For anyone who wants silicon you can study, this is great. No, it’s not as simple as sending a board off to a fab house, but it’s a start. The fact that SiFive chose to start with Open Hardware is great, and we can’t wait to see the other hardware made with their sweat and hydrofluoric acid.

It’s a Beginning

At the base level, the HiFive 1 is a powerful microcontroller with a lot of Flash, with support for hundreds of Arduino libraries. That’s great, and alone this might be worth the $60 price of admission.

However, the big story here is the Openness of the HiFive 1. Is it completely open? No. the HiFive 1 itself uses an FTDI chip, and I’ve heard rumor and hearsay the FE310 chip has proprietary bits that are ultimately inconsequential to the function of the chip. A strict interpretation of Open Hardware will not allow this board to be called Open Hardware. Those who advance this interpretation are dumb, and to counter this argument I will quote the man himself:

…We need to distinguish levels in the design of a digital product (and maybe some other kinds of products). The circuit that connects the chips is one level; each chip’s design is another level. In an FPGA, the interconnection of primitive cells is one level, while the primitive cells themselves are another level. In the ideal future we will want the design to be free at all levels. Under present circumstances, just making one level free is a significant advance.

– Richard M. Stallman, Free Hardware And Free Hardware Designs

A design that fails to be completely Open does not deserve to be grouped with designs that are explicitly closed.

Nevertheless, this is the best we have so far, and it is only the beginning. We’re going to have more microcontrollers that are more Open, but until then, the HiFive 1 is actually a pretty cool board.