Since a few people asked, I’ve posted the source code for the Backcountry Logger. In a first for me, the source is offered with a specific license. In this case, it’s the Creative Commons BY-NC-SA 3.0 license. I feel a bit silly discussing licenses here, but I see some possibility for the Backcountry Logger to turn into a bit more than just a personal project, and I’m attempting to protect that possibility. I’m happy to have people learn from the code, offer suggestions for improvements, and use it in their own hobby projects, but I’d hate to see it taken wholesale and turned into part of a commercial product.

The next step for me (once I’ve received the necessary parts) is to build a v3 logger prototype, which I’m calling the mini logger. The mini logger is the 2 x 1 inch version using an OLED display and a single AAA battery. In constrast, the classic logger that was demoed here earlier is 2.75 x 1.75 inches, and uses an LCD display and CR2032 watch battery. While reviewing the mini logger’s design yesterday to create the bill of materials, I realized that it’s really not all that much smaller than the classic logger. And the mini is actually just as thick as the classic, if not thicker, due to its AAA battery. It seems likely there will be further prototypes after the mini, attempting to get a good balance of size and features. I’ve been thinking about a version more like the classic, with the LCD and CR2032, but with all SMD parts and the mini’s extra EEPROM. That would require finding a primary source for the raw Nokia 5110 LCD, instead of buying it on a breakout board from Sparkfun.

Once I’ve got a few prototypes built, I hope to get them in the hands of some outdoorsy people who can put them to use, and offer feedback. What looks great on the bench may not work very well in the field, so real-world testing will be essential.

This is a device that should appeal to any outdoorsy people interested in examining altitude, temperature, or pressure movements over timescales from an hour to two weeks. That includes hikers, climbers, skiers, trail runners, cyclists, kayakers, snowmobilers, horseback riders, and probably many others. You can get similar information from your GPS or altimeter watch, but few of those offer detailed graph views, and GPS’s don’t have the battery life needed for long trips in the wild. An app for a GPS-equipped smartphone might work, but toting your smartphone on your adventure isn’t ideal. The closest similar devices are probably the Garmin Foretrex 401, Garmin eTrex Summit (discontinued), or Suunto Core.

I’m also thinking this project needs a better name than “Backcountry Logger”. Nobody wants something called a “logger”– that’s either a guy who cuts trees, or a tool for making boring lists. “Backcountry” is an awkward word as well. Besides being a mouthfull, it also sounds like it excludes potential uses in the civilized world like skiing or urban adventures. A good name is also probably a short name. Maybe something like “Sportview” or “Outdoor Tracker”. Bah, I’m no good at names!

Slow progress continues on the assembly and first boot-up of Tiny CPU. The photo shows a sample program written in Tiny CPU assembly language, drawing a color pattern on the LCD. The serial port and keyboard interface haven’t yet been added to the board, but the Max II CPLD, SRAM, and Flash ROM are all working fine from both an electrical and a design standpoint. After the initial round of swearing at the soldering iron, there were no further electrical problems at all, so all the work has been on configuration and software. The goal of designing a novel CPU architecture and implementing it in hardware has been met successfully.

Of course it’s not all roses and sunshine, and several smaller problems plus one big one have slowed progress and cast doubt on future direction. Debugging has been a major challenge. When things don’t work as expected, or do nothing at all, there aren’t many good tools to help diagnose the problem. The best tool I’ve found thus far is TopJTAG Probe, a $100 software program that lets you examine the current state of any pin, and display continuously-updating state data in a waveform-style window. It’s great for examining external signals at the pins, but the internal machine state remains invisible. It’s also limited to about 400 samples per second due to its use of JTAG boundary scan, which requires slowing the CPU clock to around 100 Hz to do any debugging. My free trial expires in 17 more days, and I’m undecided whether I’ll purchase it.

Altera also offers system debugging tools, including a scriptable Tcl console, in-system sources and probes, and a virtual JTAG interface. Not surprisingly, these tools all require on-chip logic resources, and Tiny CPU has few LE’s to spare. The most promising tool looks like their Signal Tap II logic analyzer, but it requires on-chip RAM, and the Max II has none. Altera doesn’t appear to offer any tools that work purely through JTAG boundary scan without any on-chip logic resources, like TopJTAG Probe. I thought the jtag_debug interface of the scriptable Tcl console might be what I was looking for, but I was unable to get it to work.

When the CPU is running, it’s pretty slow. It took four seconds to fill the LCD with the color test pattern shown in the photo. Much of that is due to the inefficiency of the bit-banged SPI code I wrote to communicate with the LCD, but the 2.6 MHz clock speed is also a factor. The 2.6 MHz is provided by the Max II’s on-chip oscillator, whose frequency is fixed. It can be divided down using logic if a slower clock is needed, but it’s not possible to go faster than 2.6 MHz. According to the timing analysis report, the CPU should run at up to 40 MHz.

Design Disaster

The biggest problem by far is the bank-switching design. Tiny CPU has a 10-bit address space, enabling 1K to be addressed directly. The companion module Tiny Device performs bank switching, mapping 128 possible 512-byte banks of RAM and ROM into the lower and upper halves of the CPU’s address space. When I first described Tiny CPU’s bank switching design, it seemed a clever and elegant way to expand the address space. After working with it in real programs, however, it feels like a complete disaster. It’s confusing and cumbersome. It complicates the design of the programs, the assembler, and Tiny Device. It makes simple things hard. In short, it needs to be taken out back and shot.

Jumping between routines in different banks requires locating the code such that the first instruction of the routine in the target bank is at the next consecutive address, modulo 512, after the instruction in the source bank that alters the bank register. In this way, execution “falls through” to the target bank, transparently to the CPU, by altering the bank register. In practice I’ve found it very difficult to line up the addresses of entry and exit points in different banks. There’s probably some way to abstract it into a general jump table in each bank, but I haven’t found it yet. Adding a new “far call” CPU instruction might help, but I’m very reluctant to embed knowledge of the bank register in the CPU itself, since at the moment it’s just a memory-mapped port handled by Tiny Device.

Given time, the bank-swapping procedure may seem more intuitive and less onerous, but I’m skeptical. And unfortunately 1K is small enough that programs need to deal with bank swapping a lot. It’s even more common than it seems at first, since the upper half of the CPU address space is always mapped to a fixed block of RAM, so programs running from ROM really only have 512 bytes of space to work with before they need to worry about swapping.

Ideally I’d like to increase the address space to something larger, but that would force major changes all over. The 16-bit instruction encoding uses 6 bits for opcode and 10 bits for address, so a larger address space would mean larger instructions. The assembler would need to be substantially altered. And of course the Verilog source for Tiny CPU and Tiny Device would need major alterations as well. My enthusiasm for such a large refactoring right now is pretty low.

Maybe the best use of Tiny CPU is as a small soft-core to incorporate into larger FPGA designs, where a simple microprocessor is needed and the 1K address space limit is not a problem. It would offer an even smaller alternative to soft-cores like PicoBlaze, and be easily portable to any vendor’s FPGA hardware. In this scenario, Tiny CPU would be used alone without Tiny Device, and the RAM and ROM would likely be FPGA logic resources rather than actual external components.

 I leave tomorrow for a 10-day trip, so I’ll think it over while I’m away and decide how to proceed with Tiny CPU development when I return.

The first Backcountry Logger prototype has gotten a very positive response from everyone I’ve showed it too, so I’m toying with the idea of making a few and selling them. I put together a bill of materials to estimate the cost, using the newest “shrunken” v3 prototype that’s designed but not yet built (still waiting for PCB and parts to arrive). As designed, the BOM cost is $32.01 each for quanity 100. That doesn’t include the PCB itself (probably a dollar or less for that quantity), the cost of assembly, or a case. For a quantity 1 prototype, the BOM cost is $37.20, but that assumes acquiring some parts as samples/free that aren’t for sale in individual quantities.


In addition to being smaller, the Logger v3 actually has more features than the v2 prototype shown in the photo here. The features require additional parts that increase the cost:

• $4.95: external EEPROM memory (allows storing more data samples and at higher resolution)
• $2.76: voltage booster/regulator (necessary because v3 uses a 1.5V AAA battery instead of 3V CR2032 watch battery)
• $4.58: vibration sensor (this is a totally new feature I added, to detect when you’re in motion and attempt to count your steps)

To build the v2 design, you could omit all those parts and lower the BOM cost to about $20.

The cost could likely be lowered further by searching for the cheapest component suppliers (I just used Digi-Key for everything), and by tweaking the design to use fewer and cheaper components.

Oof. See that window to the left? That’s the result of 10 hours of debugging effort on bring-up for my custom Tiny CPU board. What you see is UrJTAG connected to the JTAG interface of the Max II CPLD, and successfully detecting the 29LV040B flash ROM that’s also on the board. Getting to this point was a long process covering everything from software to cleaning up bad solder joints.

The good news: I’ve soldered the Max II CPLD, Flash ROM, and SRAM to the board, and they seem to be working. By using UrJTAG and the EXTEST instruction, it’s possible to disconnect the CPLD’s core logic from the pins, and set the pin states to any arbitrary values. The software also needs to be told which pins are connected to the address bus, data bus, CS, OE, and WE. Once that’s done, it’s possible to read and write any non-JTAG device whose pins are connected to the CPLD, by bit-twiddling the CPLD pins. Using UrJTAG’s commands for memory access, I’ve successfully written and read from the on-board SRAM, and reprogrammed the on-board Flash ROM. That should be nearly everything that’s needed to start work on the Tiny CPU core itself.

Interaction with the Programmed Design

I find JTAG and especially the UrJTAG tool to be maddeningly difficult to understand. Things don’t work how I’d expect, or don’t work at all, and I can’t be certain if it’s a hardware problem, software bug, or misunderstanding on my part. The best example is the reason that it took me so long to reach the point where the Flash ROM was successfully detected: interaction between the core logic (the design programmed into the CPLD) and the EXTEST pin manipulation. From what I’ve read, there should be no interaction. When the EXTEST instruction is executed by the JTAG controller, then the pins should be decoupled from the core logic. It shouldn’t matter at all what design is programmed into the CPLD, what that design wants to do with the pins, or whether any design is programmed at all.

After long experimentation and electrical testing, I discovered that the core logic design does matter when interfacing to other devices with EXTEST. Whether this is normal, or the result of a boundary scan software bug in UrJTAG, I don’t know. What I found is that if I programmed the CPLD with a design that declared the data bus as type inout (which it is, of course), then I could read from the SRAM and Flash but not write to them. By sticking a multimeter on the pins, I found that data bus pins driven to a logical 0 using EXTEST worked fine, but data bus pins driven to a logical 1 just went into a high-Z state instead, so I could never write a ‘1’ bit. I also learned that if I set the data bus type as output, then I could no longer read from the RAM or Flash. Only when I set the data bus type to input could I both read and write using EXTEST. This is nonsense on a several levels, as it shouldn’t be necessary to reprogram the CPLD with a new design just to use the EXTEST functionality. The only explanation I can think of is that the boundary scan register uses 3 bits to define the state of each pin (input, input with pull-up, output driving 0, output driving 1, output driving Z, and a few others) which UrJTAG may not handle properly, with some bits carrying over from the programmed design. I had a similar problem when using a trial version of TopJTAG Flash Programmer, however, so I’m not sure I can blame the software.

JTAG Bit-Banging

As another example of UrJTAG strangeness, the board has an LED connected to IO97, such that the LED illuminates when the pin value is 0. It should be possible to blink the LED using UrJTAG’s set signal command, e.g:

jtag> set signal IO97 out 0

After much tearing out of my hair, I learned that while that’s part of it, it’s also necessary to explicitly put the device in EXTEST instruction mode first, and explicitly shift the instruction and data into the device, as UrJTAG does none of this for you:

jtag> instruction EXTEST
jtag> shift ir
jtag> set signal IO97 out 0
jtag> shift dr   (the LED turns on)

A little cumbersome, but at least it works. In contrast, I was never able to get the corresponding get signal command to work at all. After setting IO97 to 0 as above, which visibly turns on the LED, the value of IO97 still reads as 1:

jtag> get signal IO97
IO97 = 1
jtag> shift dr
jtag> get signal IO97
IO97 = 1

The ability to twiddle pins arbitrarily through JTAG could be a huge aid to debugging, but not if the corresponding ability to read the current pin state doesn’t work.

If anyone has some experience using UrJTAG for this kind of troubleshooting, please leave a comment, or contact me by email. Thanks!

Hot diggety damn! I believe I’ve successfully soldered the Max II in its cruel 100-pin package with 0.5 mm pin spacing. At least, I’ve assembled enough of the board to connect it to a JTAG programmer, program an LED blinky routine to the Max II, and confirm that it works. There could still be all kinds of pins shorted or broken, of course, but at least I know I didn’t fry it completely.

Soldering that chip wasn’t fun. It took me about two hours just for that single TQFP 100. I used the drag soldering technique, where you goob tons of solder onto the pins and create pin-to-pin solder jumpers like crazy, then go back afterwards with solder wick to clean up the jumpers. At least that’s the idea.

I had the absolute worst time trying to wick away the jumpers. No matter what I did, the extra solder on the pins wouldn’t soak into the solder wick. I set the wick on top of the pins that had jumpers, then set my iron on the wick, and pressed down onto the sandwich. The solder underneath the wick would melt, but it wouldn’t go anywhere. When I removed the iron and wick, the jumpers remained right where they’d been, with nothing at all soaked into the wick. I applied flux everywhere, over and over, but it didn’t help.

This pattern went on for ages, and I got more and more upset. I started swearing at the board, using every profanity I could think of. I had to close the windows so the neighbors wouldn’t hear. After a while, I started singing random profanities to the tune of opera while I worked on the jumpers. I burned the soldermask off several of the traces, burned the board, and re-heated the same pins so many times that I was certain nothing was left inside the chip but melted slag. All in all, it was not a good time.

Eventually I stumbled onto a few techniques that helped a little, raising my wicking success rate from 0.1% to maybe 20%.

• Some jumpers can be cleared simply by touching the iron briefly to the pins, without any wick.
• Don’t stretch out the wick braid. Keep the strands pressed together, like stranded wire.
• If a stubborn bit of solder refuses to be wicked away, add more solder. A huge glob is actually easier to remove than a tiny fleck.

Assuming the other as-yet-untested pins on the Max II are OK, then assembling the rest of the board should be cake.

The Tiny CPU boards arrived yesterday from Seeed Studio’s Fusion PCB service. Now it’s time to break out my soldering iron again, and get busy with that 0.5 mm pitch 100-pin TQFP. Ugh!

I placed the order with Seeed on June 6, and received the boards on June 23, so that’s 17 days of calendar time from order to mailbox. Considering how slow shipping from China can be, I’m pretty happy with that. It’s actually not much slower than the 12 day turn-around time I got from Dorkbot PDX’s PCB service, which is done in the USA.

The Tiny CPU board is 100mm x 80mm, or about 12.4 square inches. For 10 boards with 50% e-test, the cost was $25 plus about $7 for shipping. I actually received 12 boards instead of the promised 10. Five boards were taped together and marked with a black line down the edge, so I assume those are the ones that were e-tested. The other seven boards were stacked on top, then the whole bundle of 12 boards was shrink-wrapped, packed in bubble wrap, and packed in a small box for shipping.

The quality of the boards looks pretty good, especially considering the dirt cheap price. Drill holes look nicely centered, and tracks look neat and clean. It’s not all perfect though, and the overall quality level feels a bit less than the Dorkbot PDX boards. There’s a bit of variation in soldermask and plating from board to board, and some of the boards look pretty scuffed up. There are also some odd numbers and a line that were added to my silkscreen layer, which I could do without.

Um, what the heck is 35186H2 and 01895Q-10? And moreover, what is that curved arc in the silkscreen layer extending from LED1 all the way to the board’s edge? None of that appears in my top silkscreen Gerber. It’s not a huge deal to have some random extra numbers and lines, it doesn’t affect anything of course, but it’s a bit annoying.

Two of the boards have some pretty significant damage from scraping or impact. I’m not sure if it’s enough to cause a failure, but it definitely might. One board is damaged on the top, and the other on the bottom, and when you stack them the damaged spots overlap. I’m guessing some sharp object got caught between these two boards, and ground away the soldermask where it rubbed against them. Maybe this is why I got 12 boards instead of 10?

I tented my vias with soldermask this time, or tried to anyway. In theory, 100% of the vias should be tented. In practice, most of the vias are tented, but some aren’t, and the fraction of tented vias varies quite a bit from board to board. Here’s the same section from two different boards, where one is 100% tented and the other is maybe 25%.

Overall I’m fairly happy with these Seeed PCB Fusion boards: decent build quality and cheap pricing. Yes, there are a few dinged and damaged boards, but given the total number of boards for the price (and the two bonus boards I received), I can call those throw-aways and still have a good deal. I would certainly use them again. For smaller boards where the costs are comparable, though, I would favor Dorkbot PDX’s PCB service, since it’s a few days faster and seems to be a bit higher quality.