Mike Tsao geeks out.

A very early and surely broken board layout. On the left are the...

Thu, 16 Feb 2012 14:03:05 -0800

A very early and surely broken board layout. On the left are the power jack, USB port, and micro-SD slot. The socketed chip in the middle is the SRAM, and the one on the right is the 6809E. The middle guys are the CPLD, an ATmega32u4, and the frickin’ huge oscillator that I will no doubt replace with an SMD version. A friend has graciously offered to do the layout for real, so I’m not too concerned about the ugly EAGLE autoroutes. I just want to get an idea of how big the board will be.

Known errors in this version:

There’s no JTAG header. I intend to program the CPLD with the ATmega, but I’d like a backup plan.
I might want to consider a fuse. This isn’t a general-purpose board with wildly varying current needs or likelihood of short-circuits, but still, it’d be smart.
There’s no circuitry to choose between USB and jack power sources. I’m OK with this; if I plug in both simultaneously, I deserve the consequences.
I phoned in the capacitor placement. I will read the datasheets and take their advice.
As-is, any SD card placed in the board would burn up. Voltage-dividing resistors between the 5V ‘32u4 and the 3.3V card signals are needed.
Like the oscillator, the SRAM could be switched to an SMD version. Only the 6809E is unavailable as an SMD.

Missing functionality:

Video.
Sound.
Game inputs.
Anything that could even theoretically serve as the Williams Special Chip.
Header sockets for a future stacked board that will eventually contain all of the above.

But this is OK. As long as I add the headers, this will serve as a fairly functionally complete 6809E-based computer with persistent storage, huge DRAM, huge ROM, and… virtually no way to demonstrate that it’s doing anything at all except through a logic analyzer or maybe Quinn’s HexOut tool. Again, this is OK. I’ll add the second stackable board, and that’s when it’ll start to do cool stuff.

Parting thought: if the SRAM is an SMD, the 6809E is rotated 90 degrees, and things are scrunched together as closely as possible, then it’s starting to look a lot like a very special-purpose Arduino shield. The Arduino would replace the ATmega, the crystal, the power circuitry, and the ISP header. That saves a lot of room on the board. In fact, it might even leave room for v2 to have everything from the missing-stuff list. Hmmm.

Wanted: CLI EDA

Wed, 15 Feb 2012 14:00:05 -0800

That’s command-line interface electronic design automation.

I’m surprised that hardware engineers design schematics and circuit boards graphically. By that I mean that they drag shapes around in a GUI editor. Behind the scenes all the polygons and line segments are being represented much more simply as Component A, Pin 1 being connected to Component B, Pin 2, or Component C at position (X, Y) on the surface of the board. Nobody in software design seriously uses graphical editors to make software, and if they do, it still gets checked into source control as plain-text, diff-able files.

As you can probably tell, I’ve gotten sick of EAGLE, and my evening investigating KiCad did not go well, partly because I tried it on OS X. I’m intrigued by gEDA, because the project origins suggest it has been designed by people who appreciate the modularity of Unix tools. The gEDA-generated, human-readable design files of the Diavolino suggest that it’s close to what I have in mind.

I don’t know the first thing about autorouting algorithms, but I wonder whether schematic and PCB layout could be looked at as a constraint-solving problem. Component A scores higher when it’s placed toward the middle of the board, Capacitor B’s traces can’t be longer than N millimeters from Component C’s Vcc/GND pins, etc. A friend suggested I look at Minion, which seems to be in the right ballpark. I think it’d be cool to edit a bunch of text source-code files (just like VHDL!), compile them, see a PNG of the schematic and/or PCB, and then spit out Gerbers when satisfied. I could fit circuit design more closely into the software-design workflow I’ve gotten accustomed to.

Free Range VHDL

Tue, 14 Feb 2012 14:00:05 -0800

Free Range VHDL:

This is a revised version of The Lo-Carb VHDL Tutorial and the Shock and Awe VHDL Tutorial, both by Bryan Mealy. Recommended.

Maxim DS1077 Programmable Oscillator

Mon, 13 Feb 2012 14:04:05 -0800

The Maxim DS1077 is a programmable oscillator. Instead of ordering different oscillators for each different project you have, you get just one on a SparkFun breakout board and program it, using I2C, for whichever frequency you need.

And in fact, after some stumbles on my part, yes, it works.

Things I Learned About the DS1077, The Hard Way

The I2C interface (a.k.a. TWI or two-wire interface) depends on someone (i.e., you) to pull SCK and SDA high. Toss some pull-up resistors on those lines. I think there’s something cool going on with this protocol that I might be able to exploit for 8821’s bus arbitration. Must read more.
The Bus Pirate doesn’t turn on its power supply until you tell it to. This is very much a feature, not a bug.
SDA and SCK are not interchangeable. I hope you didn’t need the internet to tell you that; I almost did.
The Bus Pirate’s MOSI connection isn’t labeled for I2C, but it’s what drives the SDA line. This makes sense (master-out, slave-in) but I had to look it up to be sure.
When you’re at your wits’ end and not understanding why your lines are full of random glitches, try changing the wires. Sometimes even simple things like wires can be no good!

For posterity, here’s the Bus Pirate sequence I used to program my DS1077 with an approximately 4.03MHz signal on OUT1, with the two CTRL inputs disabled:

HiZ>m
…
4. I2C
…

(1)>4
I2C mode:
1. Software
2. Hardware

(1)>2
Set speed:
1. 100KHz
2. 400KHz
3. 1MHz
(1)>1
Ready

I2C>W
POWER SUPPLIES ON

I2C>[ 0xb0 0x0d 0b00001000 ] (Don’t write every change to EEPROM)
I2C START BIT
WRITE: 0xB0 ACK
WRITE: 0x0D ACK
WRITE: 0x08 ACK
I2C STOP BIT

I2C>[ 0xb0 002 0b00011000 0b00000000 ] (Use just the 10-bit frequency divider)
I2C START BIT
WRITE: 0xB0 ACK
WRITE: 0x02 ACK
WRITE: 0x18 ACK
WRITE: 0x00 ACK
I2C STOP BIT

I2C>[0xb0 1 0b00000111 0b11000000] (Write 31 (133MHz/(31+2)) to divider)
I2C START BIT
WRITE: 0xB0 ACK
WRITE: 0x01 ACK
WRITE: 0x07 ACK
WRITE: 0xC0 ACK
I2C STOP BIT

I2C>[0xb0 0x3f] (Write out the settings to EEPROM)

By the way, this is my first time using the Bus Pirate for a project. I’ve tried a couple times but bounced off because of v4/v3 incompatibility pains. I’m not in love with the interactive serial-terminal interface. But I do appreciate the idiot-proofing, such as starting up with all signals in high-impedance mode. That’ll keep me from destroying my equipment someday, for sure.

Son of '9572 is alive

Fri, 10 Feb 2012 11:20:06 -0800

A good night’s rest didn’t help the ‘9572. It remains destroyed. After talking it over with a few people, I believe any of the following is possible:

It was close to death already from having powered it from 5 volts for so long, and it simply gave out.
I was careless with a logic probe pin and briefly touched two opposing outputs.
While juggling pins on the UCF, I uploaded a new program that caused Possibility #2 to happen. I don’t think this was the case, because I think I would have noticed it when I rearranged the pins.
Or the chip just died, maybe from ESD, maybe from cosmic rays. It does happen.

No matter what the cause, I don’t think it was the VHDL, and I don’t think it was a currently-held misunderstanding on my part. So I’m back in the saddle with one of the Dorkbot PCBs.

As you can see, the latch clock is tied to the 1MHz Q clock. I managed to flick the latch button for less than a millionth of a second during the clock’s rising edge (it doesn’t look right on this graph, but I think this is sample error or else a difference in opinion between the Saleae and the ‘9572 about when the level fell again). The high value is latched into D0 on the next rising edge, then it’s shifted to D1 as D0 obtains the new low value, then it goes from D1 to D2, etc. Then about 21 clocks after that, we see it shift through A15. If I had more probe pins, we would have been able to see it go all the way from D0-D7, then A0-A15.

There is a bug in this code. The shift into D0 doesn’t happen until the rising edge after the one that should have latched it in. I will investigate. (Update: that was easy. I changed the REGISTER_TEMP vector from a signal to a variable so that it was evaluated in the order of the statements in the process block. There’s probably a better way.)

On the Origin of Circuits

Thu, 09 Feb 2012 16:41:06 -0800

On the Origin of Circuits:

Dr. Thompson peered inside his perfect offspring to gain insight into its methods, but what he found inside was baffling. The plucky chip was utilizing only thirty-seven of its one hundred logic gates, and most of them were arranged in a curious collection of feedback loops. Five individual logic cells were functionally disconnected from the rest– with no pathways that would allow them to influence the output– yet when the researcher disabled any one of them the chip lost its ability to discriminate the tones. Furthermore, the final program did not work reliably when it was loaded onto other FPGAs of the same type.

The '9572 is dead

Thu, 09 Feb 2012 11:20:06 -0800

I killed my CPLD Breakout Board. While taking pictures of the “successful” SRAM-loading VHDL I’d written and wired up, I noticed that the power LED on the board was off. I checked the connections, toggled the power a few times, tried re-running the logic analyzer, and eventually concluded that the board was dead. It draws 1.4 amps when I plug it in, and the CPLD itself gets pretty hot. As far as I can tell, everything else on the board is working (except for the power LED, which now appears to be inert).

Here’s my VHDL:

architecture Behavioral of SRAM_LOADER is
  signal REGISTER_TEMP : STD_LOGIC_VECTOR(23 downto 0);
begin
  process (CLK)
  begin
    if (rising_edge(CLK)) then
      REGISTER_TEMP <= REGISTER_TEMP(22 downto 0) & LATCH;
      if OE = '1' then
        ADDRESS <= REGISTER_TEMP(23 downto 8);
        DATA <= REGISTER_TEMP(7 downto 0);
      else
        ADDRESS <= "ZZZZZZZZZZZZZZZZ";
        DATA <= "ZZZZZZZZ";
      end if;
    end if;
  end process;
end Behavioral;

I think the tri-stated address and data pins are the problem. None of them were connected to anything (except four data pins hooked to my logic analyzer). But I’m not at all sure why that would be a problem. The only reason I think it’s related is that one of the last things I did was testing OE disabled (grounded), but it wasn’t the last thing (which was one more OE-high run to take a picture of the registers shifting), so even that evidence is questionable. If I’d obviously shorted something external to the chip, then I doubt I’d have been able to spend the half-hour or so when I successfully tested it. That’s why I believe I did something wrong with the tri-stating.

If you know a way that one could destroy an XC9572XL CPLD by programming it incorrectly, I’d appreciate a tip.

My goodness I’d forgotten how hard it is to solder...

Tue, 07 Feb 2012 11:20:06 -0800

The three boards, before assembly.

WORST SOLDER BRIDGES EVER

Board #1 working, next to proud sibling

My goodness I’d forgotten how hard it is to solder surface-mount devices. But I did it, and one of three XC9572XL breakout boards is working. Rehash of experience in approximate order of occurrence:

Wanted to work on a different, software project tonight, but the boards arrived in the mail and they were so purple that I had to work on them right away.
I don’t understand how any SMD component could be smaller than 0603. Seriously, they make 0204, but 0603 almost floats if I breathe in the same room as it.
Dangerous Prototypes, you’re good guys and all, but did you really put the three inline LEDs in different polarities? I burned up one and reworked four in the process of figuring that out.
Despite triple-checking, I put the 10K resistors where the 2Ks go. More rework.
To remove solder bridges from gull-wing QFP leads, clean the tip, flux the heck out of the bridge, and press gently on it. Bam! Ready to ship.
Did I say flux? Yes, flux is totally, utterly awesome for making solder just do the right thing.
Your CPLD breakout board will kinda sorta accept an XSVF if the 3.3-volt IO jumper is off. In fact, the kinda sorta acceptance is exactly the same as if you’d done a cold solder joint here or there, or maybe shorted a capacitor, or left some conductive flux on the board, or…. Anyway, after ruling all those things out you’ll try the jumper and find that it programs perfectly well.

I’ll finish the other two some other time. Right now, I’m so happy this first one works!

Not to blame. These are two 100uF capacitors that were recently...

Sun, 05 Feb 2012 16:40:05 -0800

Not to blame. These are two 100uF capacitors that were recently on the main board of the Wells-Gardner 19” K7201 monitor in my Joust. They’d obviously burst over the years (notice the bulge in the cross-shaped tops), so I replaced them. Fingers crossed, powered up… and just as dead as before.

Discrete logic chip, I hardly knew ye. This is the 74HC109 (dual...

Sat, 04 Feb 2012 11:20:05 -0800

Discrete logic chip, I hardly knew ye. This is the 74HC109 (dual JK flip-flop) that I was using in my original Q/E clock generator circuit. Now that I’m using CPLD and mostly satisfied with the experience, I’m not sure when I’ll use these guys again.

The top screenshot shows a perfect Q/E clock signal generated...

Sat, 04 Feb 2012 09:47:39 -0800

Saleae Logic: 1MHz Q/E from 4MHz clock

XC9572XL connected to oscillator

The top screenshot shows a perfect Q/E clock signal generated using a 4MHz clock source. No biggie; we’ve seen this before. Right?

The bottom photo shows what’s interesting about this particular clock signal. The XC9572XL is using my very first VHDL that I wrote all by myself, programmed using The JTAG Whisperer! I found a JK flip-flop out on the web, and wired up two of them using the recommended clock circuit in the 6809E datasheet. Synthesized it, generated an XSVF, and pow! It worked!

VHDL is turning out to be exactly as I’d hoped: it’s a text-based schematic entry language. Wire std_logic A to std_logic B, conjure up an imaginary signal here and there, proofread, and then call it all into existence. I’m still finding some parts of the language confusing, and the XSVF step is certainly tedious, but I’m already willing to declare the development process fun.

Code follows.

entity QE_CLOCK is Port ( OSC : in STD_LOGIC; Q_CLK : out STD_LOGIC; E_CLK : out STD_LOGIC); end QE_CLOCK; architecture Behavioral of QE_CLOCK is component JK_FF_VHDL port( J,K: in std_logic; Reset: in std_logic; Clock_enable: in std_logic; Clock: in std_logic; Q, NQ: out std_logic); end component; signal ff1_k : std_logic; signal ff1_nq : std_logic; signal q_clk_temp : std_logic; signal e_clk_temp : std_logic; begin ff1: JK_FF_VHDL port map (e_clk_temp, ff1_k, '0', '1', OSC, q_clk_temp, ff1_nq); ff2: JK_FF_VHDL port map (q_clk_temp, ff1_nq, '0', '1', OSC, ff1_k, e_clk_temp); Q_CLK <= q_clk_temp; E_CLK <= e_clk_temp; end Behavioral;

The 6502: A Documentary

Fri, 03 Feb 2012 11:20:05 -0800

The 6502: A Documentary:

Go Quinn! Go Bill!

TTL Voltage and Current Cookbook Recipe

Thu, 02 Feb 2012 11:20:06 -0800

Now that I’m able to do something with this CPLD, I’ve been concerned about replacing $10 of discrete logic chips with a $2 chip that needs $8 of level shifters. Though the Xilinx XC9572XL is a fairly modern 3.3-volt device, I know its I/O pins are 5-volt tolerant, meaning that I can send in a 5-volt signal from my circa-1980s 5-volt 6809E. But the ‘72’s output voltage is selectable at either 3.3v or 1.8v, and not 5v. And as established earlier, 5 volts do not equal 3.3 volts. What to do? Some inspired laziness (“maybe it’ll just work”) led me to read the ‘09 datasheet, and then do a bit more general research.

And I have concluded that yes, maybe it’ll just work. TTL logic levels define a low as zero to 0.8 volts, and a high as 2 to 5 volts. Why not exactly zero and exactly five? Well, there needs to be some margin for error. We software engineers like to think of pure concepts like binary zeroes and ones. But on the oscilloscope, real-world logic values sometimes look like a nervous driver on a twisty road at night. (Sorry, that link is a PDF, but it nicely illustrates what the 45- and 90-degree angles in datasheets really look like.) So low is a range, and high is a range, and 3.3-volt digital logic values are entirely consistent with 5-volt ranges. It’s… as if… (concentrating very hard now)… when The Powers That Be wanted to move to lower-voltage — and thus lower-power — electronics, they didn’t come up with a new standard so much as pick tighter tolerances for the old one. 3.3 is almost exactly in the middle of the old 2- to 5-volt range, and there’s probably some other practical reason why it’s easier to generate 3.3 volts than 3.5 volts.

Anyway, speculative history lessons aside, I’m pretty sure the 6809E will recognize signals from the 3.3-volt I/O lines of the CPLD. I’ll wire something up before committing it to a PCB, of course, but everything I’ve read suggests this will work.

Here’s the current ingredient list for Prototype Board #1:

Two power supplies: 5 and 3.3 volts.
6809E.
128KB SRAM.
MicroSD card slot.
ATmega32u4.
16MHz crystal.
XC9572XL.
DAC for audio, with an audio jack.
DAC for video, with a video-out header.
Game-control input header.
[Placeholder for generating the digital side of the video signals.]

The ‘32u4 is the star of the show. I think it can do all these things:

As a JTAG Whisperer, program the CPLD during development.
Read the SD card and set up part of the SRAM as ROM from the perspective of the 6809E.
Assert the 6809E’s reset line when everything’s set up.
Handle all the 6821 game-control PIA duties.
Depending on what’s left, maybe even output sound using PWM.

Meanwhile, the CPLD should be able to do this:

Manage the address and data bus.
Turn the 16MHz crystal into the ‘32u4’s clock, and into the Q/E signals. I don’t yet know whether a CPLD can turn a crystal into an oscillating signal.
In a dream world where I’m much smarter than I am, fit the Williams Special Chip blitter into the 72 macrocells.
Feed the digital video signals into the resistor ladder.

And of course the several-dozen other jobs I’ve forgotten. Phew!

More than you ever wanted to know about electrical characteristics of JTAG

Wed, 01 Feb 2012 11:20:06 -0800

A few days ago I posted a very confused question about JTAG signals. Here is my less confused answer.

You’ve surely seen the cup-or-face picture before, where some see two people looking at each other, and others see a single white chalice in the middle. Both groups are correct, and fortunately everyone can easily tell their brains to see the other image, too. That’s what happened with me and JTAG signals. I saw this:

Write TDI/TMS.
Set TCK.
Wait.
Clear TCK.
Wait.
Read TDO.

And the code I originally wrote probably would have worked just fine like this. But it didn’t, so I scoured the web looking for working examples (none of which was both working and targeted toward the Arduino, unfortunately). Most were some variation of this:

Read TDO, write TDI/TMS.
Clear TCK.
Set TCK.

Which seemed to be out of whack with the spec (if not the spec then XAPP058). I conformed my code; it still didn’t work. I permuted the bit-banging code madly. It still didn’t work. I found subtle logic bugs that didn’t matter, because it still didn’t work after I fixed them. I was ready to see five fingers when O’Brien held up his hand.

As you already know from prior entries, the voltage fiasco was the answer. My code would never have worked with the hardware running at 5 volts instead of the required 3.3. But in my experience, the nice thing about debugging code in an impossible situation is that by the time you figure out and solve the thing that was making it impossible, the rest of the code is absolutely perfect because you’ve debugged the living daylights out of it.

Now that I have working hardware and have been able to run some experiments, I’ve started seeing the cup instead of the faces. It’s not that TCK’s signals are inverted (active-low); it’s that the master divides the work into two categories:

Stuff I care about.
Everything else.

Its job is to write out TDI/TMS before TCK goes high, and to read TDO after TCK goes low. But it’s OK for the work relative to TCK’s edges to overlap. For example, I can write TDI, then clear TCK, then set TCK, because TDI was still set before TCK’s rising edge. It just looks weird because it seems like the code is saying “set TDI before TCK’s falling edge.” Nope, TDI and TCK’s falling edge have absolutely nothing to do with each other. Taking the transitive closure of dependencies, yes, TDI and TCK’s falling edge are related in the sense that TCK’s rising edge comes before its falling edge, but other than that, the code is free to rearrange itself in a sensible fashion as long as it respects those constraints. (There is one timing characteristic, TDOXZ, that I am still convinced is a typo in XAPP058.) Taking out the “wait” steps from the original sequence, looking at it as a circle rather than a line of steps, and reordering slightly in that “sensible fashion,” it ends up like this:

Read TDO and write TDI/TMS, in any order.
Set TCK.
Clear TCK.

… which is exactly what most implementations on the web do. QED.

It works! Yay! The main problem all along was that I was running...

Tue, 31 Jan 2012 19:22:53 -0800

It works! Yay! The main problem all along was that I was running the board at 5 volts, not the 3.3 volts it needs. It was able to respond to JTAG commands at the higher voltage, but it correctly reported that it couldn’t write its flash memory under those conditions.

I still need to update the README for the JTAG Whisperer, but the code in the repository should work right now. Hooray!

5.0 != 3.3

Tue, 31 Jan 2012 11:20:05 -0800

I just realized that the XC9572XL’s “5-volt tolerant I/O pins” do not mean that the device itself can be powered with 5 volts. It’s a 3.3-volt device. I’ve been running it from the Arduino’s 5-volt supply.

Sigh.

With this newly understood information, I hope to discover that the JTAG Whisperer is working correctly, and that the incorrect voltage was preventing the CPLD from programming itself. Other possibilities are (1) my code is still buggy but the CPLD is happy to be finally running at the right voltage, and (2) I’ve fried my poor little ‘9572.

JTAG TCK: active-low?

Sun, 29 Jan 2012 16:42:05 -0800

Why does it seem like the JTAG clock signal is active low? Consider this snippet from Xilinx’s XAPP058 source code.

/* toggle tck LH. No need to modify this code. It is output via setPort. */
void pulseClock()
{
setPort(TCK,0); /* set the TCK port to low */
setPort(TCK,1); /* set the TCK port to high */
}

This means that when the clock isn’t being pulsed, it’s high. Right? If so, why don’t any descriptions of JTAG’s electrical characteristics say it’s active low?

The JTAG Whisperer

Sun, 29 Jan 2012 11:22:05 -0800

Available here on GitHub. The JTAG Whisperer turns your Arduino into a JTAG cable. Wow, sounds great! Here are the caveats:

It’s actually just an XSVF player. This is a tiny subset of what JTAG does. The current architecture has the desktop load the XSVF file, then send it over serial to the Arduino. Since serial is going to be limited to the kilobits-per-second range of speed, it’s unlikely it’ll be suitable for more ambitious interactive JTAG operations. But it’d be interesting to see what could be accomplished with the newer Arduinos that have replaced the FTDI chip with the more flexible ATmega U-series chips.
It has been tested only on a Xilinx XC9572XL breakout board from Dangerous Prototypes, and the only function it has performed so far is asking the chip its device ID (spoiler: it’s 0xf9604093). I would have happily used the Bus Pirate’s XSVF Player firmware, but it hasn’t yet been ported to my BPv4 hardware, and I wasn’t willing to invest in learning PIC development.
It doesn’t work very well yet. The serial communication between the desktop and the PC frequently gets logjammed, and the Arduino sometimes has to ask repeatedly for the ID.

I have high hopes for this project. Its immediate use will be to program the ‘9572 so that I can start experimenting with replacing discrete logic 74xx chips. Eventually I hope it’ll become a robust, reliable XSVF player for the Arduino.

Please give it a try. I look forward to your pull requests!

Linux on Nexys2?

Sat, 28 Jan 2012 11:22:05 -0800

All the search results for [linux nexys2] discuss how the heck you run that djtgtgtgjdsasdfghjkcfg Digilent tool on Linux. In other words, how do you program the Nexys2 on Linux?

But what would it take to run Linux on the Nexys2, or a similar medium-sized FPGA? Can you just download an http://opencores.org/ processor that has a gcc toolchain for it, throw in some I/O controllers, and get the kernel booted up? I am so new to FPGA that I can’t even do a back-of-the-envelope calculation whether a Linux-capable core, plus glue, would fit. But it would be a fun project to find out!

Rescue guide for your Adafruit ATmega32u4 breakout board

Sat, 28 Jan 2012 10:19:00 -0800

The ATmega32u4 breakout board is a beta product. The hardware is essentially perfect, but the firmware is wonky. At least once, I’ve convinced myself that mine was broken, but I eventually figured it out. Here’s how to get yours back in shape.

Things required to get all the way through these steps:

The board
A USB cable to connect the board to your computer
A working copy of avrdude. If you have the Arduino IDE on your system, then it’s buried deep inside the IDE.
Possibly an in-system programmer. These instructions will work with any USBTiny-compatible programmer.

Before we get going, a warning: the fuses and the bootloader must match, because the fuses tell the chip where the bootloader is. If you have the Leonardo bootloader on your board, beware! That one uses a different fuse combination (I think FCD5C3) from the Adafruit one (FCD0C3). Moreover, you need the ISP to change the fuses; an ATmega32u4 unfortunately can’t change its own fuses. It’s completely possible for you to flash the wrong bootloader to the board, leaving it in a zombie state, needing the ISP to fix it. This means that these steps might take you from a sort-of working board (e.g., an early Leonardo bootloader) to one that’s completely broken (the Adafruit bootloader with the wrong fuses), and if you don’t have an ISP to set the fuses, you’ll be stuck. TL;DR: if you have a board that mostly works, and don’t have an ISP, then stop now.

If your board is showing up as a serial device, we can learn a little from it directly, without the ISP. Run avrdude -c avr109 -p m32u4 -v -U lfuse:r:-:i -U hfuse:r:-:i -U efuse:r:-:i -P /dev/tty.usb_path_to_the_device_serial_port. A bunch of information should get spit out, ending with something like this:

avrdude: safemode: lfuse reads as FC avrdude: safemode: hfuse reads as D0 avrdude: safemode: efuse reads as C3 avrdude: safemode: Fuses OK

If you get an error, it’s possible your board is running the Leonardo bootloader, so you’ll need to ask differently. Instead of avr109 in the previous command, try arduino.

Now you want to figure out what those fuses mean. Visit the AVR Fuse Calculator (in fact, you might want to set that as your home page) and type the three into the “Current settings” fields at the bottom of the page. Apply values, then go back up to the top of the page and see what the “Boot flash size” dropdown is set to.

If the size is 2048, this is GOOD because it’s what matches the known-good 2K Adafruit CDC bootloader. If this size is anything else (probably 512), then stop unless you have an ISP because you need an ISP to change the fuses. If the size is not 2048 but you do have an ISP, proceed to change the fuses.

To change the fuses, plug your board into your ISP and run avrdude -v -c usbtiny -p m32u4 -U lfuse:w:0xFC:m -U hfuse:w:0xD0:m -U efuse:w:0xC3:m. Again, skip this step if your boot flash size is already 2048.

Next, flash the one true bootloader that today is known to work: BootloaderCDC.hex. Run either of these commands, depending on whether your board is connected to the ISP or directly to your machine:

Directly connected: avrdude -c avr109 -p m32u4 -P /dev/tty.usb_path_to_the_board_serial_port -U flash:w:BootloaderCDC.hex

Connected to your ISP: avrdude -c usbtiny -p m32u4 -U flash:w:BootloaderCDC.hex

Note that, unlike in the previous step, I am not telling you to substitute arduino for avr109 in this step. That’s because doing so would kill your board and require the ISP to rescue it. If you wanted to follow that step, it means you misunderstood the earlier steps about current bootloader size.

By this point, you should have BootloaderCDC on your board, and fuses for a 2048-byte bootloader. Plug the board via USB into your computer. You should see the pulsing green light as well as a new serial port on your computer. All should be well.