Storing passwords with the ATmega32U2

Earlier this month, the HackADay crew confirmed that it had chosen Atmel’s ATmega 32U4 microcontroller (MCU) to power an offline password keeper known as “Mooltipass.”

As it turns out, a Maker by the name of Josh is working on a similar offline password keeper, albeit with an ATmega32U2 instead of the 32U4.

Like the Mooltipass, the USBPass is connected to a computer via USB and read as an HID keyboard. Aside from the ATmega32U2, the platform is equipped with a minimal amount of components, including a USB connector, three buttons and a few passives chips.

“A total of 20 passwords can be stored in the microcontroller’s memory, which can be ‘typed’ by the platform using the push buttons,” explained HackADay’s Mathieu Stephan.

On the software side, the USBPass firmware is based around the LUFA USB stack, to which Josh added HID report functionality to facilitate data transfer from his desktop application.

“The latter uses the Linux/Windows/OS X HID API library so bringing his software to other operating systems can be done in no time,” Stephan added.

Although the current version of the USBPass is pretty sweet indeed, Josh says he is working on a second iteration of the platform which will likely boast an OLED screen.

Interested in learning more about the Atmel-powered USBPass? You can check out the project’s official page here and the relevant GitHub files here.

C64 DRAM testing with an ATmega8U2

Josh (aka Axlecrusher) was working on restoring an old Commodore 64. The stalwart computer was missing a few obvious pieces, prompting Josh to make a new AV cable and obtain a new power supply, all while replacing the PLA, VIC and capacitors. However, the C64 still didn’t boot properly, so Josh decided to test the Commodore 64’s DRAM chips.

Photo Credit: WIkipedia

“My particular C64 uses 8 individual RAM chips most are D4164C-15 and a couple are D4164C-2. I replaced all the RAM but I wanted to know if both the original and replacement chips were functioning properly. I decided to test each chip, I needed some hardware to test with,” Axlecrusher explained in a blog post.

“I decided to use [Atmel’s] ATmega8U2 AVR microprocessor (MCU), because I have one that can plug into a breadboard and it has enough pins to drive the D4164C chips. I wired the test setup to try to reduce the instruction count where I could so it is a little messy. Wiring and instruction count could be greatly improved if I didn’t need the programming header, but it gets the job done.”

According to Axlecrusher, the first task was simply trying to write and read just one bit, with the datasheet for the DRAM provided timing windows charts for each required step. After a few hours of stepping through the charts, coding, re-coding, reviewing the charts, and sometimes just trial and error, Axlecrusher was finally able to write and read 1 bit from memory.

“After a couple more days of work I was reading and writing to the entire memory module. I constructed a couple of routines to test both the wiring and the memory. To test the wires I wrote 0 to the first bit of the memory followed by a 1 to a power of 2 memory location (high on just 1 wire). I then read memory location zero and if the value is no longer 0, it indicates a failure on a specific address wire,” he continued.

“I used a walking one algorithm with a bit inversion to test all the memory cells. The goal is to toggle as many bits as possible. In either case if there’s an error, the red LED would turn off forever. While the test is running, the LED will blink at the end of each complete cycle. I was able to test all the memory modules I had replaced. They were all functioning properly.”

Interested in learning more about C64 DRAM testing with Atmel’s ATmega8U2? You can check out Axlecrusher’s original blog post here and the source code on GitHub.