Changing BORAs firmware – the hard and the easy way

So BORA is great, but there’s this thing I don’t like. The clock. 25kHz , fixed. I don’t want that.  I want 100kHz. Or 38kHz.
In fact, I want to determine that  frequency myself.
The clock is generated on the AVR. So I need to change the AVR code to get a different clock.

Fortunately, they’ve added an article on how to update the firmware of the AVR.

Unfortunately, they only added the hex-Files to that article.

Changing the firmware – the hard way.

I spent several hours on researching disassemblers (well, to be specific, it’s a reassembler) to convert hex into asm.  I finally settled for ReAVR.


A bit too much for a human brain, isn’t it?
The first check was to just compile it again and compare.
(This is why I settled for ReAVR. Didn’t work out with AVR studio.)

There are three pieces of information I have:

1) I know the processor type. It’s this one:

2) It has a 8MHz clock

3) It has 25kHz and writes it to some register. I have some reason to assume it’s actually based on 4Mhz , so I’m not only looking for a factor of 320, but also keeping an eye out on 160.

That register is pretty much defined


I didn’t think I’d be lucky enough to find something that divides by 160 or 320, but searching for “out” gives a limited number of occurences. And even less places where they’re writing my register and I can find out the register for the clock and –

I need to get a life.

(Assume I spent ages drawing call graphs and flow charts from that code, and relearning assembly, which was very, very rusty. Took me all night to detangle the code, mainly because there’s actually a reason we’re using symbols and decent programming languages like C.)

I did eventually find a counter to 160. But trying to edit this within the hex code turned out to be a mess. I eventually ended up recompiling it – first, tried it with the “regular version” (which worried me a bit by producing a somewhat different output, but seemed to produce working code), then writing 0x00 to the output register, then by actually doing my thing).

I got it running. But I’m not going to include the solution, because I’m not 100% sure I didn’t accidentally change something important. And because I found a so much better way to do this.

Changing the firmware – the easy way.

Now, the most cruel thing about this was that it was about 4am, and I figured out there’s a git-repo for bora.

Yeah. Probably should have googled earlier.

You need

– git
– probably mingw / msys / some sort of shell if you use windows
– avr-gcc (use WinAVR, and if you use Win7 64 bit, don’t install it into the Programs(x86) folder. Use the suggested folder)
– doxygen, if you want to read the documentation

The repository is

You’re looking for the ..\avr_firmware\LUFA-120730\Projects\BORAMaster folder.

There is a file called BoraHID.c

Open it in some editor, like NotePad++. Go to line 107.

/* Enable 25 kHz clock output */
DDRB |= 1<<7;
TCCR0A = 1<<COM0A0 | 1<<WGM01;
TCCR0B = 1<<CS00;
OCR0A = 160;

Yeah, our famous 160. Change it to, for example 105, if you want 38kHz.

OCR0A = 105;

Open your folder in a dos shell.
You’ll get a hex file. BoraHID.hex
To upload it, follow the instructions here

(My next blog post will include more detailed instructions for FLIP, so hold on or read the help)


38kHz. Done, baby.



  1. Josh · · Reply

    Firmware dissambling of an obscure board for no good reason on a Friday evening. Marry me?

  2. […] ‹ Changing BORAs firmware – the hard and the easy way […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: