How to set fuses on AT90USB series

While trying to enable DebugWIRE on our new AT90USB162 microcontrollers, we encountered this error:

$ avrdude -c jtag2isp -p usb162 -P usb -v -t
>>> write lfuse 0 0xde
avrdude (write): error writing 0xde at 0x00000, rc=-6
avrdude (write): error writing 0xde at 0x00000 cell=0x5e

avrdude: safemode: lfuse reads as 5E
avrdude: safemode: hfuse reads as D9
avrdude: safemode: efuse reads as F4
avrdude: safemode: lfuse changed! Was de, and is now 5e
Would you like this fuse to be changed back? [y/n] n

Erasing the controller with avrdudes’s -e option fixed the problem:

$ avrdude -c jtag2isp -p usb162 -P usb -v -e
$ avrdude -c jtag2isp -p usb162 -P usb -v -t
>>> write lfuse 0 0xde

avrdude: safemode: lfuse reads as DE
avrdude: safemode: hfuse reads as D9
avrdude: safemode: efuse reads as F4
avrdude: safemode: Fuses OK

avrdude done. Thank you.

Initial support for Asix Sigma in Sigrok


Last year we worked on reverse engineering the Sigma logic analyzer to provide a decent Linux experience. The project stalled somewhat, but a few weeks ago, we we’re contacted by Bert Vermeulen from the Sigrok open source logic analyzer software. They wanted a driver for the Sigma, and asked if we could provide it. After some more work looking at the protocol, we were able to understand how to program the analyzer.

Because of potential copyright issues with regard to distributing the firmware, we contacted the vendor. They turned out to be very supportive of the project, and agreed to put the firmware under a license that allows redistribution. In addition, they provided detailed documentation of the protocol, which allow us to understand all the gritty details of the communication dialog.

It is therefore with great pleasure that I announce initial support for the Sigma in the Sigrok logic analyzer software. The driver is far from complete, as it only supports 200 MHz capture, and with only using software triggers. However, with the detailed specifications provided to us by Asix, and the continued dialog with their developers, we will bring full support for the Sigma to the Sigrok project.

The Asix Sigma is a nice piece of hardware with 16 channels and up to 200 MHz sample rate, available for € 298.- at ASIX’s homepage and from third party resellers.

Some udev trouble

Ubuntu decided to move /proc/bus/usb to /dev/bus/usb recently, and this caused some problems with our ASIX SIGMA Logic analyzer. The proprietary library libftd2xx used by the wine wrapper has this path hard coded and will bail out without any warning. It is not possible to symlink from /proc/bus, but libftd2xx also provides an alternative location for usbfs: /dev/usb.

Example udev rule:
SUBSYSTEM==”usb”, ATTRS{idVendor}==”a600″, ATTRS{idProduct}==”a000″, GROUP=”555″, MODE=”0770″, RUN+=”/bin/sh -c ‘ln -s /dev/bus/usb /dev/usb’”


My first adventure in PCB production

The finished clock

After being a member of PING for a while I got more and more interested in electronics and microcontroller programming. As I didn’t own a standalone digital clock, I decided to make one myself. We had all the necessary components: Seven-segment displays, a microcontroller and appropriate resistors.


Multiplexing the displays

I connected every segment on all the displays to pins on the controller, and the ground pin of each display to their own pins on the controller, as seen here:

Multiplexing the displays.
Multiplexing the displays.

To give the illusion that all the displays are on, I quickly connect the ground pin of the first display to GND, and the active segment pins to VCC, disconnect the ground pin of the first display, and then repeat the procedure for each display forever.

Programming the controller

Updating the display

I constantly update the displays:

    putdigit(DISP_0, hours/10,   seconds & 32);
    putdigit(DISP_1, hours%10,   seconds & 16);
    putdigit(DISP_2, minutes/10, seconds & 8);
    putdigit(DISP_3, minutes%10, seconds & 4);
    putdigit(DISP_4, seconds/10, seconds & 2);
    putdigit(DISP_5, seconds%10, seconds & 1);

putdigit updates each display:

static void putdigit(uint8_t display, uint8_t digit, uint8_t dot)
    int i;

    PORTA = pgm_read_byte(&seg[digit]);

    if (dot)
        PORTA |= SEG_0;

    for (i=DISP_0; i<=DISP_5; ++i)
         PORTC |= (1 << i);
     PORTC &= ~(1 << display);

The fonts are stored in program memory:

static uint8_t seg[] PROGMEM = {
    SEG_1 | SEG_2 | SEG_3 | SEG_5 | SEG_6 | SEG_7,
    SEG_1 | SEG_7,
    SEG_2 | SEG_3 | SEG_4 | SEG_6 | SEG_7,
    SEG_1 | SEG_2 | SEG_4 | SEG_6 | SEG_7,
    SEG_1 | SEG_4 | SEG_5 | SEG_7,
    SEG_1 | SEG_2 | SEG_4 | SEG_5 | SEG_6,
    SEG_1 | SEG_2 | SEG_3 | SEG_4 | SEG_5 | SEG_6,
    SEG_1 | SEG_6 | SEG_7,
    SEG_1 | SEG_2 | SEG_3 | SEG_4 | SEG_5 | SEG_6 | SEG_7,
    SEG_1 | SEG_2 | SEG_4 | SEG_5 | SEG_6 | SEG_7,
    SEG_1 | SEG_3 | SEG_4 | SEG_5 | SEG_6 | SEG_7,
    SEG_1 | SEG_2 | SEG_3 | SEG_4 | SEG_5,
    SEG_2 | SEG_3 | SEG_5 | SEG_6,
    SEG_1 | SEG_2 | SEG_3 | SEG_4 | SEG_7,
    SEG_2 | SEG_3 | SEG_4 | SEG_5 | SEG_6,
    SEG_3 | SEG_4 | SEG_5 | SEG_6,
    SEG_3 | SEG_4,
    SEG_3 | SEG_4 | SEG_1 | SEG_5,

where SEG_? corresponds to these physical segments:

 * Segments:
 *   6
 * 5   7
 *   4
 * 3   1
 *   2   0

Timers, buttons and interrupts

Putting the digits on the displays is well enough, but this is a clock, so we want to update the time as well. Enter the timer. I enable the internal timer on the Atmega16, and make it trigger an interrupt every second:

TCCR1B |= (1 << WGM12);
 TIMSK  |= (1 << OCIE1A);
 OCR1A   = 15624;
 TCCR1B |= (1 << CS12)  | (1 << CS10);
 MCUCR  |= (1 << ISC11) | (1 << ISC10) | (1 << ISC01) | (1 << ISC00);
 GICR   |= (1 << INT1)  | (1 << INT0);

The interrupts need to be handled, so I make them increment the seconds variable:


    if (seconds == 60)
        seconds = 0;

        if (minutes == 60)
            minutes = 0;

            if (hours == 24)
                hours = 0;

The only thing missing now is a way to set the time. For that, I use one button for incrementing minutes, and one for incrementing hours:

    hours = (hours + 1) % 24;

    minutes = (minutes + 1) % 60;

The final prototype

I hooked a breadboard up to an STK500 developement board, and connected everything together.

The final prototype.

The finished product

After a night of etching and soldering, this was the result.

IR-RF transceiver: Part I – Taking stuff apart

A few weeks ago I discovered a cheap wireless power control set from Clas Ohlson. At first I intended to use it with my universal remote, but this turned out to be impossible because the universal remote was infrared (IR) only, and the power unit was RF (433 MHz). So I would have to shell out $400 for a more fancy remote… or, I could hack the light controller!

I wanted to add an IR receiver to the RF remote control, and use it as a transceiver / repeater, so I could use my universal remote to control the RF light switches.

2010-02-14 18.53.21

Opening the remote

I brought the gear to PING, where Håvard and I disassembled it. The remote control contains two PCBs:

  • Frontend with 6 buttons, an LED, a channel selector, a 12V battery, and a signal encoder chip
  • Backend with RF unit

The two PCBs were connected with GND, SIG (+5v) and VCC (+12v).

Decoding the protocol

Trace of "A1 ON" command

Physical layer

We hooked up our logic analyzer between the two units, and recorded the signal.

The physical layer protocol was easy to reverse by looking at the trace, two patterns was clearly visible: 1000 and 1110. It looks like each data bit is represented by four bits in the physical layer; a start bit (high), the data bit repeated twice, and then a stop bit (low).

0 = 1000
1 = 1110

Data link/application layer

We then tried to analyze the higher level protocol, first we decoded channel A, lamp 1, button “On” and “Off”:

0001 0101 0001 0101 0101 0111 0
0001 0101 0001 0101 0101 0100 0

Finding the difference was easy; 11 is on and 00 is off.

Next we needed to understand the addressing, and so we recorded and decoded most of the possible “On”-signals:

A1-ON : 0001 0101 0001 0101 0101 0111 0
A2-ON : 0001 0101 0100 0101 0101 0111 0
A3-ON : 0001 0101 0101 0001 0101 0111 0

B1-ON : 0100 0101 0001 0101 0101 0111 0
B2-ON : 0100 0101 0100 0101 0101 0111 0
B3-ON : 0100 0101 0101 0001 0101 0111 0

C1-ON : 0101 0001 0001 0101 0101 0111 0
C2-ON : 0101 0001 0100 0101 0101 0111 0
C3-ON : 0101 0001 0101 0001 0101 0111 0

D1-ON : 0101 0101 0001 0101 0101 0111 0
D2-ON : 0101 0101 0100 0101 0101 0111 0
D3-ON : 0101 0101 0101 0001 0101 0111 0

So each packet (which was repeated several times when pushing a button) had the following structure:

CHANNEL-NO[6] 01 LIGHT-NO[6] 01 0101 01 STATE[2] 0


A = 000101
B = 010001
C = 010100
D = 010101


1 = 000101
2 = 010001
3 = 010100

Cleaning Lady Attack Possible on Debian and Ubuntu Desktop

We have recently discovered that possibly all screensavers with lock capabilities are prone to a cleaning lady attack. By issuing Alt+SysRq+f you (or a malicious cleaning lady) can make the OOM killer kill your screensaver process and give you access to the screen. This works with xscreensaver, xlock and gnome-screensaver (Debian Bug). As a hotfix, you can write

# echo 446 > /proc/sys/kernel/sysrq

to disable killing of processes with Alt+SysRq+f.

CC-BY-SA Torkild Retvedt
CC-BY-SA Torkild Retvedt

Sampi – A Logic Analyzer

Not completely true; Right now, Sampi is only a frequency counter, but our aim is to create a logic analyzer that is far more advanced than any tool we know of. The project started after we bought a ASIX Sigma software based logic analyzer. Great hardware, but the supplied software was useless. As a result, we started developing open source logic analyzer software.

Some of the design goals are:

  • Fast user interface that can be fully controlled using the keyboard
  • Multiple modes of plotting input data
  • Python scripting support. This can be used to write decoders on-the-fly, and the verify that protocols behave correctly.
  • A library of protocol specifications which can be used to simply debugging (e.g. SD/MMC card protocol)

Sampi is written in C++, licensed under GPL and is vendor independent. This means that all software logic analyzers can be used with a driver.


The SIGMA used during development contains an FPGA, but requires that the configuration (firmware) is uploaded by USB on every boot. To grab the firmware, we simply intercepted the USB traffic with a LD_PRELOAD wrapper. This worked well, but a more reliable method was desired. The firmware resides in a obfuscated format in the windows binaries provided free of charge by the vendor, and after a little trickery, we were able to extract it. A tool to extract the firmware to use SIGMA in open source software is available in our git repository.


Electronic Door Lock: A 2009 Approach

Since PING expanded to more than a handful active members, we have had several generations of door locking solutions. The first solution involved a long IDE-cable, a CD-ROM and a computer which issued the eject command in order to control the lock. The 2009 revision of the door lock is the most advanced and stable so far, and has the following features:

  • A strong mechanical lock
  • Username/password authentication in a graphical UI
  • RFID authentication
  • Bluetooth authentication

The design consists of five modules:

  1. The locking mechanism (industry standard electric door lock)
  2. The lock controller board (Atmel ATTiny 461 SMD) with locking, USB and RFID firmware
  3. RDM630 RFID reader connected to the lock controller by UART
  4. Computer controlling the graphical user interface (placed outside the room), connected by ethernet
  5. Main control computer (connected to the GUI through ethernet, and lock controller through USB)

It will probably not score any points for looks, but it provides ease of use and some safety to our premises.

The circuit was designed in Kicad and routed using FreeRouting. Source code and circuit is of course available in our git repository with GPL license.

The lock has three magnetic sensors onboard to detect bolt position and if the door is open or closed. The sensors, a button and the RFID chip is monitored by an ATTINY 461 connected by USB to the host computer. We use the V-USB implementation by obdev, which enables us to have a low-speed USB interface to the AVR with very few extra components.

The motor which engages the bolt requires a 12 V power supply, and USB only delivers 5V. This was solved by using a DC BOOST converter (LT1373) providing enough power over the USB line. To control the motor we designed an H-bridge using BJT transistors.

The RFID chip sends tags (14 byte hex) by 9600,8,N,1 UART as soon as a tag is sensed. The ATTINY does not have an UART, so our firmware emulates this by synchronizing to the bitstream.

The host computer runs a simple program that validates RFID tags and provides an interface for openening the door. It also monitors Bluetooth connections. Users entering username or password to unlock the door do so on a dedicated computer located outside our office. This computer and the host computer communicates by a secure TLS connection.

As a result of this project,  members of PING are now able to unlock the office door by using their username and password, by presenting their RFID proximity card, or by having Bluetooth enabled on their mobile phone.

Software, Hardware, Electronics, Whisky, and Other Hazardous Materials