05/06/2018 at 01:20 •
Lately, I've been working on getting a JTAG for FPGA infrastructure up and running.
The goal of this is two-fold:
- Simply learn to work with all the tools involved: RTL, OpenOCD, UrJTAG etc.
- Create some open source equivalents of tools that exist for Altera and Xilinx, but not for open source tool flows such as the one for Lattice FPGAs.
The first installment simply talks about a small JTAG controller GPIO block that can be used to replace Altera's In-System Source and Probes debug block.
The first article in the series can be found here.
05/01/2018 at 06:45 •
In an earlier log, I already wrote about needing a microscope to solder probe wires onto the pins of a TQFP 144 package.
The microscope in question is a Bausch and Lomb StereoZoom 4. There’s a really good article about this microscope here, but the gist of it is this:
- It was produced from 1959 to 2000(!) and sold under the brands of Bausch & Lomb, Leica, and Cambridge Instruments.
- By far the most common configuration has a zoom ratio of the main body from 0.7x to 3.0x, with 10x eye pieces.
- It’s a stereo-microscope which means there is a sense of depth. This helps a bit when doing soldering work.
The article linked earlier goes in quite a bit of detail on how to calibrate and align the eyepieces etc. This was not necessary with the one that I bought. All I had to do was make some minor adjustments for my left eye.
An original manual can be found here.
There are two kind of stands:
- Boom stands, which have a heavy base, a vertical bar and a horizontal bar. That’s the kind that I have, and the one that I would suggest other to get as well. They make it much easier to mount larger PCBs on a flat surface and you can simply move around the base.
- “Regular” stand, like the ones used in biology labs etc.
The most common configuration comes with 10x eye pieces. With the main body magnification going from 0.7x to 3.0x, that gives a total magnification from 7x to 30x.
My scope came with 15x ehye pieces instead. I don’t think it makes a huge difference. When soldering, I also keep the scope set at the lowest magification: 0.7x.
Where to Buy It?
eBay or Craigslist!
As I write this, there are tons of them available on eBay.
They are offered with a boom stand, regular stand, or no stand at all: just the body, in which case you need to buy one separately (or improvise and make your own?)
Prices are absolutely all over the place.
Having followed a bunch of auctions on eBay, it’s clear now that I got mine for an absolute steal: $95. Similar configurations sometimes go for $200 and more: $550, even $800. (For these kind of prices, you should be able to find much better soldering microscopes, such as old models from Vision Engineering.)
Boom stands go for $50 to hundreds of dollars on eBay.
LED Ring Illuminator
You don’t strictly need an illuminator: a lamp on the side will work fine. In fact, when using the phone adaptor, I found that I got best results with the illuminator switched off: the LED light would refect off the metal of the pins and the phone couldn’t really deal with that. However, when not using the phone, it is simply so much easier to get exactly the right amount of light and change the intensity as needed.
At the bottom of the main body is a recessed ring in which you can screw an illuminator adaptor (or additonal lenses as well.) This ring has a diameter of 1.5” or 38mm. Most illuminator rings that I could find on Amazon where from AmScope which expects a recessed right of 48mm.
However, you can find an AmScope to StereoZoom ring adaptors that will convert from 38mm to 48mm … for $35 and up.
I ended up buying a $25 64 LED AmScope ring illuminator and I use painter’s tape to attach it to the microscope. It’s ugly, but it works.
Mobile Phone Adapter
I wanted a mobile phone adapter for two reasons:
- to be able to work with the microscope without looking through the eye pieces. I need to wear glasses when I do soldering work and not looking through the scope. Having to switch all the time between putting them on to look at a data sheet or so, and putting them off when doing the actual work is a bit annoying.
- to take pictures of what I’m doing and post it on a blog. :-)
I bought both to compare them. The ones with eye piece cost about double ($22 vs $12).
Here’s the one with the eye piece:
With an iPhone 8 Plus:
Mounted on the microscope:
In terms of usage, there’s simply no contest. The one without the eye piece was a pain to align against the eye piece of the microscope, and there were major issue with glare from stray light.
There are no such issues with the eye piece integrated model. It’s pretty easy to put the phone in the holder in seconds and have it in the right position.
The resulting pictures and videos are pretty good too!
In terms of settings, I typically set the microscope to 0.7x magnification, with the iPhone camera set to 2x.
If I set the iPhone to just 1x, you get a large black unused area. Like this:
It’s totally possible to set the microscope to 3x, but in that case you lose a lot of depth of view: you can focus on the bottom of a TQFP144 pin and have the top of the pin unsharp or vice versa. As can be seen here:
Nothing prevent you from making videos, such as this one from a previous post:
I’m not an animal who makes videos in portrait mode, but portrait mode is the natural position of the holder when inserted into the microscope. So more painter’s tape was required to keep the phone in landscape orientation.
04/29/2018 at 16:55 •
I have a few projects going on that require reverse engineering the command stream between different chips. For example, in my eeColor Color3 project, there is no programming documentation of the I2C registers of the Silicon Image SiI9233.
So one way or the other, I need to probe the I2C bus of this chip.
The good news is that the chip has a TQFP144 package which means that the pins are out in the open. The not so great news is that TQFP pins are spaced 0.5mm away from each other.
My initial plan was to buy some very small probes that can connect to those pins. The second plan was to solder wires on the pins.
In the end, the second plan worked out great and was completed long before I could try out the first plan, but since the wheels of the first plan had already been put in motion (I had ordered the probes), I might as well share my experience with those little probes.
The High End Stuff
A good example are these SMD grippers. I’ve used them at work. They are spec’ed to grip pins that are 0.5mm away from each other. They also cost $39 per gripper. Ouch.
There are two cheaper options, such as another pair of SMD grippers (at $9 each) and a set of 10 (at $12 each).
Having used similar of these grippers as well, they are clearly of lower quality than the first ones. If you absolutely need these kind of probes (and your employer is willing to pay for them), just spend the money.
But for a hobbyist, they are too expensive.
Much cheaper, $5 each, are these Pomona grabbers on Adafruit. They seem to be an excellent choice for SOIC packages, but are probably too big for my 0.5mm spaced TQFP144 pins.
Micro Chip R/W Clip
So let’s get over to AliExpress and see what’s available.
You’d expect there to be plenty of alternatives, and you’d be wrong. I may have been using the wrong keywords to find the right product, but the smallest grippers are for SOIC-type packages (which have a pitch of around 1.2mm.)
Until I stumbled on the Micro Chip R/W Clip. Surprisingly, they are marketed as a tool that allows you to reprogram a car remote control key IC. Including shipping, they go for about $15. $1.5 per probe, not bad.
3 weeks after ordering, the following box arrived at my door:
The package has the follow contents:
The grip of the probe is surrounded by a long and a short side. The long side is the one where the clamps will come out. The short side can be pressed in to push the clamp out. The metal of the probe has a transparent plastic layer around it:
Unlike the high end grabbers, there is no easy way to push on the short end of the probe: it’s too sharp to press with your bare finger. Instead, you need to plug in the black connector and then press on the connector. However, even if you do that, the black connector will come loose from the wire that’s inside it. So you actually have to push on the connector and the colored wire at the same time.
It’s not super practical, but it works, as long as you have your two hands available: one to hold the probe, the other to push.
Hands On - TSOP 0.8mm
So how do they work in practice?
Here’s a small example where I connect a probe to various pins of an SDRAM:
The 54 pin TSOP has the pins spaced 0.8mm from each other. It’s clear that probing a single pin is pretty easy.
Probing 2 adjecent pins is a bit harder but it’s definitely possible as well:
But that’s about the limit: the probes themselves as just too wide reach 3 closely spaced pins.
Hands On - TQFP 0.5mm
Finally the case that started it all: probing an I2C bus on a TQFP 144 package.
It takes a little bit of effort, but probing a single pin is very doable:
But that’s where it ends. If we zoom in a little bit more, we see the grabbers of the probes marked by the orange rectangles:
It isn’t encouraging: the gap between the grabber and the next pin seems to be narrower than the width of the grabber itself.
After a lot of trial and error, I was able to squeeze a second grabber next to the first one, but I was never able to do so with the two making contact. And since the I2C pins were right next to each other, there was no way to probe them at the same time with these grabbers.
The probes are cheap and they are small enough to grab isolated pins on a TQFP144 package or pairs, adjacent pairs of a TSOP. You’re out of luck if you need to probe adjacent pairs on the TQFP144, which made them useless in my case.
If you have the tools (solder iron, microscope, very thin wires), soldering probe wires is much more effective solution, with the additional benefit that the measurement setup is far less fragile.
That said, I’m happy to have these probes in my toolbox. They’ll be useful one day.
(A backup version of this log can be found here.)
04/18/2018 at 05:41 •
(Also published here.)
I was supposed to work on getting the SiI9233 up and running, but UPS delivered a nice package today:
I had an urgent need to measure something meaningful.
Since I don't have a microscope (yet) to solder some really tiny wires on the TQFP144 of the SiI9233 (I want to record all I2C transactions to see how the thing gets configured), I decided to have a closer look at the difference between a high quality $50 Terasic USB Blaster and the cheap $3 Chinese clone that's available on AliExpress, eBay etc.
The Terasic version is supposed to be an Altera sanctioned design that has a chip USB to parallel converter chip from the FTDI family, and a small CPLD that converts the parallel data into JTAG (and some other formats).
The Chinese clone contains an STM32F101 micro controller.
As I wrote earlier, the biggest issue with the cheap clone is that it doesn't work on my eeColor Color3 board.
So let's look at the signals as measured on the JTAG connector of the Color3 board.
Terasic USB Blaster
This is the first transaction that travels over the JTAG cable when you issue the "nios2-terminal" command.
The most important signal here is TCK, in yellow.
There are 3 major sections: during the prefix there are 8 slow clock cycles. In the middle there are 16 groups with fast clock cycles (each group is itself 8 clock cycles). And at the end you have a suffix with 2 slow clock cycles.
For this investigation, it doesn't matter what gets transported when, but it's almost certain that the slow clock cycles are used to move the JTAG TAP from iDLE state to the scan DR or scan IR state, and that the fast clock groups are used to rapidly scan data in and out of a scan data register.
When you zoom in on the slow clock cycles, you can measure a TCK frequency of 780kHz:
Meanwhile, during a fast clock group, the clock toggles at 6MHz. This is expected: according to the Altera documentation, 6MHz is exactly what one can expect from a USB Blaster.
In addition, there are roughly 3 idle cycles between a fast clock group.
Cheap Clone USB Blaster
And here's the equivalent of the cheap clone. For the overview, look at the upper set. The set of signals below that is a slightly zoomed in version of the one above.
We see a similar pattern, but interestingly enough, it's not the same.
We have a prefix with 8 slow clocks, but in between the second and the third slow clock, there's a signal fast clock group.
In the middle we have the expected 16 fast clock groups.
The suffix is really different, with 6 clock clocks but also a fast clock group in between.
While the Terasic was rock solid in its communication with the Color3 board. The cheap clone was never able to get reliable contact.
Zooming in on the slow clocks, we see a clock frequency of 192kHz.
A fast clock group sets the clock at 12MHz instead of 6MHz.
A really interesting difference is in the spacing between fast clock groups: for the Terasic, it was around 3 fast clocks (roughly 3x16us=48us). For the cheap clone, the spacing is huge: around 40 clock cycles (40x8us=320us).
If we ignore for a second that the cheap clone doesn't work on this particular board, the biggest consequence of the chapeau clone is that bulk transfers are much slower: (8+3)x16=176us per byte vs (8+40)x8=384us per byte.
It looks like the cheap clone is able to squeeze out bits really fast, but there's quite a bit of software overhead in processing the next byte in the USB packet.
The Terasic doesn't have that problem: there is no software. All processing is done with a simply state machine.
What remains is the question about why the cheap clone doesn't work. It's not that it's broken: the clone works fine on my EP2C5T144 mini development board. My money is on the clock speed: even with the Terasic, the signal isn't super clean, and the one of the cheap clone looks a bit worse. (*)
But the cheap clone runs TCK at exactly double the speed of the Terasic, and both devices only use a flimsy, cheap flat cable. It may be that 12MHz is really just pushing things too much. (**)
(*) Don't assume too much when looking at the signal quality: horrible things may have happened when setting up the measurement.
(**) Altera's newer USB Blaster II, which can run TCK at clocks of up to 24MHz, uses a much higher quality cable between the dongle and the JTAG connector.
04/11/2018 at 06:15 •
(Also published here.)
Dirt cheap USB blaster clones considered harmful... or at least non-functional.
My very first hobby FPGA boards was the popular EP2C5T144 Mini System Learning board with the smallest Altera Cyclone II FPGA. You can find them for $12 on AliExpress.
To program the board, you also need a USB Blaster: Altera's version of a JTAG cable. These, too, can be found on AliExpress for less than $3. It's really a steal. (Identical copies sell for $10 on Amazon.)
I've been able to make this cable work with the EP2C5 board so I thought it was all good.
However, I'm now in the process of reverse engineering the eeColor Color3 board (which conveniently has the JTAG connector still populated), and I spend more than an hour trying to get it work. Quartus was able to detect the USB Blaster, but most of the time it didn't even detect the JTAG chain. And if it did, it'd detect the wrong JTAG chip ID. And I never managed to get a bitstream programmed.
Well, you try out another JTAG clone: : the Terasic USB Blaster. It sells for $50 on the Terasic website and $70 on Amazon, which is still $230 less than the official real thing from Altera.
I plugged it in and ... voila! ... everything worked like a charm.
I suspect that the dirt cheap ones have really crappy level shifters (if they have them at all.)
04/08/2018 at 05:45 •
(Also published here.)
I'm taking a short break from the BlackIce-II to spend some quality time in my garage with the eeColor color3. Originally a real consumer product built with a Cyclone 4 FPGA, a DRAM, an HDMI receiver and an HDMI transmitter, it got its 15 minutes of fame when it was featured on Hackaday as a potentially really cheap FPGA development board.
A few people mapped out the IOs of the FPGA and built a bitcoin miner with it, but I'm not aware of any projects that are using all the features of the board.
Today, most color3 boxes sell for $20 and more (+shipping) on eBay, but I was able to grab one for just $10+shipping.
It'd be a shame if the scattered reverse engineering information of the color3 that can be found on the web would disappear due to standard web-rot, so I've started a Hackaday project and a github page to gather all the information I can find today, and, hopefully, also document my own progress in getting all the chips to work.
03/24/2018 at 06:28 •
My larger goal is to create a new firmware called "icehub" , which will enable a bunch of new development features. Instead of using the standard ST libraries, I want to use libopencm3 instead: it's an open source library that works with most Cortex based SOCs and microcontrollers.
Today, I wanted to create my first libopencm3 program, a blinking LED obviously, run it on the STM32 of the BlackIce-II board, and step through it with the debugger.
After yesterday's success of getting the Blue Pill to connect to the Blackice, this certainly wasn't going to be overly complicated! Right?!
Step 1: Adding Support for the STM32L433RCT
libopencm3 has support for "stm32l4", but only a few specific types. Our L433 was of course not part of the list.
Adding support turned out to be pretty easy: you just need to tell how much ROM and RAM it has and add that information to ./ld/devices.data.
There are a lot of examples as part of the library, and there's even an l4 directory for that, but a shared Makefile is missing. So that had to be fixed as well.
After this, I could compile the "libopencm3-examples/examples/stm32/l4/stm32l476g-disco/basics" example.
(I need to commit those changes and create a pull request for that.)
Step 2: Creating a blinking LED Program
Since I ultimately want to do a lot of USB-related stuff, I started with a usb_cdcacm example from the F1 examples directory. This forced me to start digging into the whole clock architecture of the STM32, because the F1 is really different there. Not the most efficient way to get to blinking LED.
Anyway, eventually I ended up with something that compiles.
On the BlackIce-II board, the DBG1 LED is the only one that can be controlled directly by the STM32, so that's the one!
Step 3: Running it with the Blue Pill - Black Magic Probe. And failing.
- After power, the STM32 starts to execute code from flash address 0x0800_0000.
- My blinking LED binary is also targeted for that address.
- So you need to flash that.
This is where I ran into a crucial limitation of the Black Magic Probe: it doesn't support flash operations!
So I changed the address map to create a binary that is mapped to address 0x2000_0000, the RAM of the STM32. And it gets loaded fine there. However I could not figure out to get GDB to execute from an address in that range.
I needed a different solution: my original STLink v2 dongle!
Step 4: The STLink v2 the BlackIce-II
After yesterday, I'm a wiser man now, so I added an extra GND wire between the STLink and the BlackIce board, I fired up openocd, and *HURRAY!* it connected just fine!
What's more: when you telnet into openocd, you can issue flash read and write operations!
And that's what I did:
- I reverted my linker 0x2000_0000 changes
- Built a binary for flash address 0x0800_0000.
- Flashed it with openocd
- Linked GDB to openocd
- "load cdcacm.elf"
- "br main"
- "continue" (run somehow doesn't work)
- BOOM! It just worked!
What's more: the LED was blinking correctly right away!
Ultimately, I would love to debug my programs from RAM instead of flash, but for now, I'm moving back to using the STLink instead of the Black Magic Probe.
03/23/2018 at 06:38 •
In yesterday's log, I wrote about not being able to connect the STLink v2 to the STM32 of the BlackIce-II board.
Right now, that still doesn't work, but I found a work-around: I installed the wonderful BlackMagic Probe firmware on the Blue Pill STM32F103 board, which converts the Blue Pill into a debugging dongle that's actually more powerful than the STLink v2!
An STLink v2 is essentially a protocol converter from USB to SWD. You still need OpenOCD as an intermediary to link GDB to your STM32.
Not so with the BlackMagic Probe: it has acts like a serial port on the USB side, has a GDB server built-in which drives a SWD or JTAG interface. OpenOCD is not needed anymore: you connect your GDB straight to the dongle.
How did I get there?
Install Black Magic Probe on the Blue Pill
This turned out to be a combination of this article: "Converting an STM32F103 board to a Black Magic Probe"and this article: "Programming an STM32F103XXX with a generic "ST Link V2" programmer from Linux" (which I already reference earlier.)
The first article assumes that you don't have an STLink v2 dongle and compiles then installs the BlackMagic firmware using a USB to Serial dongle instead. The second one tells you how to install anything with the STLink dongle.
I wanted to use the STLink dongle to install the BlackMagic firmware.
All in all, the procedure was pretty straightforward.
- Compile the BlackMagic firmware until you have blackmagic_dfu.bin and black magic.bin
- Download BlackMagic from GitHub
- cd src
- make clean && make PROBE_HOST=stlink
- Install blackmagic_dfu.bin with the STLink dongle
- openocd -f /usr/local/share/openocd/scripts/interface/stlink-v2.cfg -f /usr/local/share/openocd/scripts/target/stm32f1x.cfg
- telnet localhost 4444
- reset halt (in combination with pressing the Blue Pill reset button)
- flash write_image erase blackmagic_dfu.bin 0x08000000
- Once installed, the Blue Pill device is now DFU capable, which means that new firmware can be installed over USB. You do not need the STLink dongle anymore to install additional firmware!
- Install black magic.bin (without STLink)
- dfu-util -d 1d50:6018,:6017 -s 0x08002000:leave -D blackmagic.bin
In the process of all this, I learned a little bit about this all works:
- The STM32F1 starts executing at address 0x08000000 and thus when the blackmagic_dfu.bin firmware was installed, it's flashed to that address.
- The blackmagic_dfu.bin has two features:
- It tests if there is valid firmware at 0x08002000. If there is, it jumps to that address and its job is done. You can see that piece of code here.
- When there isn't any valid code, then it sets itself up as a USB DFU device, making it possible to flash valid firmware. You can see this just a few lines further down.
- Consequently, blackmagic.bin is located at address 0x08002000. Since it completely takes over the board, this one also need to implement DFU mode, otherwise you'd need an additional dongle (like the original STLink) to install improved BlackMagic firmware later on!
- The BlackMagic firmware implements 3 'functionalities' on a single USB device:
- GDB (which uses a USB-to-Serial port)
- This ultimately controls SWD and JTAG pins on your Blue Pill
- UART (also using USB-to-Serial port)
- This controls UART pins on the Blue Pill.
- Instead of using the standard STM32 libraries, BlackMagic uses libopencm3, which is an open-source equivalent that can be used to many different Cortex devices from other chip companies.
Connecting the Black Magic to the BlackIce-II
I wired the following signals:
- Blue Pill GND -> GND (pin 9 of the BlackIce-II RPi connector)
- Blue Pill SWDIO (pin PB14) -> SWDIO (pin 11 of the BlackIce-II RPi connector)
- Blue Pill SWCLK (pin PA5) -> SWCLK (pin 7 of the BlackIce-II RPi connector)
Once you have BlackMagic Probe running on the Blue Pill, you can connect to it directly with gdb:
- arm-none-eabi-gdb -ex "target extended-remote /dev/ttyACM0"
- On my Linux machine, the BlackMagic Probe created /dev/ttyACM0 (GDB) and /dev/ttyACM1 (UART). If you do 'ls /dev/serial/by-id', you can see more descriptive names to connect to.
- You should see "Remove debugging using <some interface> :
ubuntu@ubuntu-xenial:~/projects/BlackIce-II/firmware/iceboot$ arm-none-eabi-gdb -ex "target extended-remote /dev/ttyACM0" GNU gdb (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 126.96.36.19971128-git Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-linux-gnu --target=arm-none-eabi". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word". Remote debugging using /dev/ttyACM0 (gdb)
- You now need to scan for STM32 devices:
- monitor swdp_scan
Note that this didn't work at first. Initially, I saw the following:
(gdb) monitor swdp_scan Target voltage: unknown SW-DP scan failed!
It took me a long to time figure what was wrong. In the end, I solved it by wiring an additional GND wire between the Blue Pill board and the BlackIce-II board. So simple!
(gdb) monitor swdp_scan Target voltage: unknown Available Targets: No. Att Driver 1 STM32L4xx
- Next, you need to tell GDB to connect to this device:
- attach 1
(gdb) attach 1 Attaching to Remote target warning: No executable has been specified and target does not support determining executable automatically. Try using the "file" command. 0x080008e2 in ?? ()
What happened now is that GDB has taken control of the ARM CPU. Whatever it was executing has been stopped now and that is that.
If you never replaced the firmware of the BlackIce-II STM32 controller, you interrupted the iceboat firmware, which allows one to download a new FPGA bitstream over the USB-to-Serial port.
Debugging Firmware on the BlackIce-II STM32
For now, let's just use an example of the existing firmware.
- Recompile the iceboat firmware as described in my wiki page here.
- You will now have a file called iceboot.elf in the ./output directory
- While in the ./firmware/iceboot directory, attach gdb to the STM32 CPU as described earlier.
- Press the reset button of the BlackIce-II board!
- This reset the CPU back to its starting position. But since GDB is attached now, it will stay there.
- Load the recompiled firmware:
- file ./output/iceboot.elf
- Set a breakpoint at the start of the C program
- br main
- Start executing
- If all goes well, the GDB will now be waiting at the first command of main.
It looks like this on my console:
Remote debugging using /dev/ttyACM0 (gdb) atta 1 Attaching to Remote target warning: No executable has been specified and target does not support determining executable automatically. Try using the "file" command. 0x080011d6 in ?? () (gdb) file ./output/iceboot.elf A program is being debugged already. Are you sure you want to change the file? (y or n) y Reading symbols from ./output/iceboot.elf...done. (gdb) br main Breakpoint 1 at 0x80012b4: file main.c, line 95. (gdb) r The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /home/ubuntu/projects/BlackIce-II/firmware/iceboot/output/iceboot.elf Note: automatically using hardware breakpoints for read-only addresses. Breakpoint 1, main () at main.c:95 95 HAL_Init(); (gdb)
- Compile the BlackMagic firmware until you have blackmagic_dfu.bin and black magic.bin
03/22/2018 at 04:57 •
I want to use my BlackIce-II board as a development and debug board for designs that can later on be moved to an FPGA-only design, where the STM32 provides a bunch of support features.
For example, the STM32 could be used to load a new bitstream, be a JTAG master to the FPGA (when you put a TAP in the FPGA), drive QSPI if you need the transfer speed, etc.
To make that work, it's really necessary to be able to use GDB during the STM32 development.
For that, you need an STLink v2 dongle that supports the Serial Wire Debug protocol. Turns out: these things are dirt cheap. You can get them on AliExpress for as low as $1.80 if you can stomach a 30 day shipping delay.
While looking for those, I also noticed an abundance of ridiculously cheap STM32F103 development boards. They go for $2.50 on AliExpress as well. (These boards are also advertised on eBay for the same price, but they *also* take more than a month to arrive.)
I didn't want to wait that long, so I bought the STLink + STM32F108 board for $12 or so on Amazon. $8 extra meant I had the thing at my doorstep 2 days later.
STM32F108 Blue Pill Development Board
Why the STM32F108? Because I already have a pile of micro controller boards. Why not have one more?
But also: there are plenty of tutorials on the web on how to get that board working with the STLink dongle and OpenOCD. So for just a few dollars more, I can replicate exactly the same configuration before I move on to great things.
I'm glad that I did.
I followed these instructions and, after swapping two wires, I had the thing going and was able to dump the contents of the STM32 flash contents. I'm currently not all that interested in getting C code to work on that one, but it should be pretty trivial, I think.
My drawer has a bunch of ATmega1280 boards from a previous life, an Adafruit Feather board with an ATmega and BLE, an LPC<something> board that I bought to see if it was still possible to an ARM7TDMI up and running (no issue with today's open source tools BTW), an Nvidia Jetson TK1 board, and some others that I'm forgetting.
But none of them are as cheap as this little thing. And it way faster than ATmega based products. If you want get into this kind of tinkering, and you want to do it cheap, these STM32F103C8T6 are absolutely the way to go.
Next step: getting it to work with STM32L433 that sits on the BlackIce-II board.
BlackIce-II with STM32L433
While the STM32F103 works find with OpenOCD 0.9.0 that comes with my Ubuntu 16.04 installation, this is not the case for the STM32L433. You need the stm32l4x.cfg configuration file for that, which is part of 0.10.0.
I started by connecting 4 pins between the dongle and the BlackIce board: GND, SWCLK, SWDIO, and 5V, and while that *did* result in some LEDs lighting up... a little bit, the FPGA didn't really come up. So I'm now NOT connecting the 5V and using USB instead to power the board. The STLink 5V is clearly not powerful enough to drive the BlackIce board.
I'm currently still at this dead-end:
adapter speed: 500 kHz adapter_nsrst_delay: 100 none separate Info : Unable to match requested speed 500 kHz, using 480 kHz Info : Unable to match requested speed 500 kHz, using 480 kHz Info : clock speed 480 kHz Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748 Info : using stlink api v2 Info : Target voltage: 3.234369 Error: init mode failed (unable to connect to the target) in procedure 'init' in procedure 'ocd_bouncer'
Connecting RST of the STLink to RESET_ of the BlackIce connector didn't work either.
So I'm stuck with that for now.
What I really want to do first is to have a multi-function interface into the FPGA with multiple virtual channels: STDIO, debugger for a RISC-V CPU, waveforms etc. If I can't get this to work, I might restore to just JTAG for a while and not use the on-board STM32L. Or I might even use the STM32F103 as driver as a temporary replacement.
03/18/2018 at 05:33 •
After laying on my nightstand for 3 weeks (during which my BlackIce-II board got all my attention), it's time to get a minimal design going.
The Upduino documentation on GitHub is a Word file that describes how to create a LED blink design with the Lattice iCECube2 software and how to program it with the Lattice Diamond programmer. I don't have those, but I decided to try if it works with Project IceStorm.
Of course, it does.
After the usual amount of struggling with command line options (forgetting to use `sudo` didn't help either), it was able to get a blinking LED going. The results can be found here: https://github.com/tomverbeure/upduino/tree/master/blink
Check out the Makefile for the right combination of command line parameters for the different tools.
- The 3-color high-intensity LEDs are really very bright
- Programming the SPI flash with the bitstream takes quite a bit longer than for the BlackIce-II even though the bitstream is 30% smaller. I think that's because the FTDI chip is used to transmit bit-banged signals over USB. The BlackIce-II is using DFU mode instead, where the bytes of the STM32 on-board flash are transmitted as bytes.
- The Upduino comes with no design loaded in its flash. As long as you don't successfully upload a design, you have no idea whether the board is fully functional. It would have been useful for the SPI flash to be preprogrammed with a design that blinks the LED.
- As soon as the FPGA has been successfully configured, the green CDONE LED goes up. It's way too bright for a status LED that will be on all the time.
- Last but not least: there something about my board that makes it pretty hot, even when not design is load at all! I think it's somewhere around the FTDI chip. This might be an issue with my board.