Categories

STM32 / FPGA Board

I put together a development board of sorts last month to test out a few different things. It consists of a STM32F4 microcontroller with its external memory interface connected to a Xilinx Spartan-6 FPGA. The FPGA has a basic VGA output as well as SDRAM to use as a frame buffer. An ethernet PHY is also attached to the microcontroller. This project serves several purposes:

  • More complex project to continue learning how to use OrCAD.
  • Test bed for an architecture I'd like to use in the future where the STM32 FSMC is used to interface to an FPGA and map "registers" created in the FPGA into microcontroller memory space.
  • Test board for DP83848 ethernet interface circuitry.
  • Not originally planned, but my first try at assembly using solder paste and reflow.

This board isn't super complicated electrically, but took a while to design because I had to create new components and footprints for most of the parts. I have a decent parts library now, so this was a good use of time though.

The challenging part for this project was assembly. I was planning to hand solder it, but the timing lined up with when I started researching reflow soldering for another project. So I decided to order a stencil and use solder paste plus a toaster oven instead. Unfortunately, I didn't get a decent photo of the board before it was fully assembled, but there is a short video clip here of the reflow process. There were a couple mistakes I made in the process. Two components (SDRAM and SPI flash) did not have stencil openings because I forgot to define paste mask openings when creating the pads for those packages. A ton of the pins on the STM32 and FPGA also ended up bridged after reflow... likely due to me not holding the stencil down well enough and getting too much paste applied. Soldering the messed up parts by hand plus using lots of solder braid to clear the bridged pins resulted in the final result shown below.

Assembled board, after a lot of hand rework.

After cleaning up all the soldering issues and getting to the point where the 3.3V rail and ground weren't shorted, I powered the board up. Fortunately, board bring-up went better than the soldering did. I was able to connect to the STM32 and the FPGA with their respective programming interfaces and verify that both were functional.

The only fail electrically was the clock source for the DP83848 ethernet PHY. The PHY requires its own 25 or 50 MHz clock source because the frequency is not a multiple of the 12 MHz crystal used for the micro. I placed a 25 MHz crystal to cover this. When reviewing the PHY datasheet before ordering parts, I discovered that in RMII mode (which I'm using) it needs a 50 MHz oscillator. A plain old crystal can only be used for 25 MHz clock when in full MII mode. I caught this and ordered a 50 MHz oscillator that fit the same footprint as the crystal I had designed the board for. Thought this solved the problem... kinda forgot that oscillators need power and ground though, which are not routed to it since I was going to use a crystal. Oh well, I'll have to bodge the oscillator in with some jumper wires before I can test ethernet.

Software wise, at this point I have some basic test code running on the STM32 and text output on VGA working. I had a mostly working verilog design for VGA output from another project, so that didn't take long. It is purely text-based, using characters from a text buffer in block RAM to index into a "font ROM" which defines the pixels to display for each character. All that had to be added was a serial interface for writing to the text buffer RAM, so the STM32 could control what was displayed.

VGA output testing.

Next step from here is to build a controller to use the SDRAM chip on board. This is needed to have a full resolution frame buffer, as block ram in the FPGA is much too small to hold a full video frame. Until then, only text can be displayed. I have read a few articles and have a pretty good idea how this will work, but it is still a significant amount of verilog to write. After that, I need to get the FSMC (external memory interface) in the STM32 set up. Communication between the STM32 and FPGA is currently only a slow serial port. Ethernet needs to be tested too. I have working code for this from another project, so it should be easy once the oscillator is fixed.

LED Matrix Clock

It's been a while since I've updated this site. There was too much going on with school at the time and I just didn't end up getting time to write projects up. I graduated a while ago now and have more free time, so I'm going to make an effort to post here again. Starting off with a small project:

I have been moving my PCB design work over to OrCAD this year and needed a simple test project to learn the workflow in the new software. Adafruit has some neat looking LED matrix modules that I wanted to use somehow. This was the result:

Finished clock.

The above photo was taken before I implemented brightness control. It is dimmed to be a bit less blinding now. The electronics are pretty simple. A STM32F0 microcontroller controls everything. Three 74HC595 shift registers drive the columns and a ULN2003 transistor array is used to switch the rows. The LEDs all run directly off 5V input power and the micro is supplied by a 3.3V regulator.

PCB side of the clock.

I made the mistake of designing around a ULN2803 (8 channels vs 7 on the ULN2003) without realizing that they come in a wide SOIC package. Ended up using a ULN2003 plus a SOT23 FET for the 8th channel to make it work. In addition, I tied the BOOT0 pin on the micro to VCC instead of GND, which forced it into bootloader mode instead of running my code. A lifted pin and another jumper wire fixed that.

Halloween Costume

It's been a couple weeks since halloween, but this is worth writing up anyway. Last year I had been thinking about doing some sort of costume using LEDs. The prices on flexible RGB LED strips have gotten really cheap, so it seemed like a good time to try to build something with them. I hadn't come up with any good ideas for what to actually make until a few days before Halloween, when a friend showed me a video of an LED stick figure costume that had gotten a lot of attention last year. So, a few days before Halloween, I decided to try building my own. Thanks to the magic of Amazon, I got a 5 meter roll of LED strip shipped next day for $15. An old sweatshirt and pants were found to attach everything to.

Putting it together was fairly simple: lay out each section of strip and cut it to length, solder wires on, then stick it in place using the adhesive back on the strip. Each section was wired in parallel so they would all light up the same color. The power supply and controller are directly connected to the section on the pants, which the sweatshirt then connects into with a 4-pin header.

Terrible mirror photo of the costume.

I only had a couple hours to throw the controller together and get everything working, so I stuck to using a Teensy 3.1 for simplicity. TIP120 transistors are used to control each of the red, green, and blue channels. The whole thing is powered from a 3S RC battery via a 5V voltage regulator. The LED strips can draw over an amp when all three colors are on full brightness, so the regulator really should have had a heat sink. As it turned out though, running the LEDs at a max of about 20% PWM duty cycle was more than bright enough at night. With the patterns I was using, power usage was only in the 100-200 mA range, so everything could run off of a tiny 1000 mAh battery for a several hours.

Controller built on protoboard in its enclosure.

Since the Teensy is programmed the same as an Arduino, getting the code working was easy. At first, I just made a simple pattern that fades in random colors. I later added a button to switch between modes and made a few more patterns. One of those was strobe mode, which flashed white at full brightness… it produced quite the effect outside in the dark!

It all ended up working well for something thrown together last minute. The adhesive on the LED strips held onto fabric better than expected, although not enough to be a permanent solution. After the first night running around with it, some of the strips were peeling off, so I spent much of the next day sewing everything on permanently. Very tedious (probably since I have no idea how to do it correctly), but made things much more durable.

Yaesu VX-6R Receive Fix

Some time in the last year my VX-6R radio started having problems receiving. On narrowband FM mode it had trouble picking anything up at all. The local weather radio station, which came in loud and clear on another radio, could barely be heard. I did some searching around and found this forum thread which described exactly the same problem. Then, while looking for the replacement part mentioned there, I found a description of the same fix here.

Conveniently, the second page above was written by Tim (WO9U), who is part of the amateur radio club at my school. I asked him about it and found out that he even had a spare of the replacement part! So today I opened up the radio and took care of it. The details are better explained in the links above, but basically it came down to replacing a filter that had failed. Tim was kind enough to not only provide the replacement part, but to bring his soldering equipment for me to use and to help with the actual repair. Having someone experienced watching certainly helped with the nervousness of taking a soldering iron to a relatively expensive radio!

After removing bad filter. (empty box above the yellow connector)

The only difficult part was removing the old filter, which took almost an hour. It should have been easier, but the soldering iron used was not meant for lead free solder and probably was not as hot as would be ideal for this.

New filter in place and ready to go back into the radio.

The replacement seems to have completely fixed the problem! Full signal strength on the weather radio station again and background noise is back to a normal level.

Skein Hash Breaking

So I think it is finally time to start updating this blog. On April 1st xkcd posted a comic titled "Externalities", which partly involved a competition to find a value that matches the most bits in a given Skein 1024 hash. I decided to write a program to automate the guessing process and see how well I could do.

With a good cryptographic hash like Skein there should be no way to predict the input used to generate a given hash. This means that the best strategy is to simply to compute as many random hashes as possible. I originally wrote a simple C# program using the SkeinFish library. It performed reasonably well at about 100,000 hashes per second, but was limited by the fact that it was single threaded and that the SkeinFish library was not the fastest. Running this for a few hours did produce a reasonable result of 411 bits different.

After a while I decided to rewrite the program properly, using an optimized Skein implementation and multithreading. The best option looked to be the Skein3Fish library in C. This was new territory for me, as all of my C experience had been on Arduino and other microcontrollers. Best way to learn is by doing!

The basic structure of the program is this: Each thread has a counter to generate input data to Skein (given how the hash works, there is no need to generate random input or anything... as far as I understand at least). A starting counter value is input when the program is started and each thread starts at this value plus a per-thread offset. The current counter value is mapped to ASCII characters and used to calculate a hash. Each thread keeps a “best” value. When a thread finds a better result, it takes a lock on the main thread and checks if its value beats the global best value. It updates the global value if it does, or updates its own best value if not. This prevents the threads from having to lock the main thread often.

I made some effort to optimize the code, although I'm sure there is still room for improvement. The worker threads only report status every ~1M hashes, the comparison of matching bits is done with the method described at http://graphics.stanford.edu/~seander/bithacks.html#CountBitsSetTable, and the code for converting the counter value to ASCII character is made as simple as possible. On a dual core i5 processor it reached almost 5 million hashes per second. A pretty nice improvement over the first version! Both myself and a friend ran the program overnight, completing about 300 billion hashes total and getting a best of 402 bits difference. Well behind the leaders but still decent in my opinion.

The source code is available here. The directory structure is somewhat messy due to starting from one of the Skein3Fish example programs, but it should be fairly easy to build using cmake. Given that it was my first serious C program and was not thoroughly tested there may still be some bugs. Feel free to let me know if you find anything, but with the competition being long over I am not planning to work on it any further myself.