July 2016

Song-book for the spy agencies

Seems spying on citizens is the new black these days, most government “intelligence” agencies are at it in one form or another. Then the big software companies feel left out, so they join in the fun as well, funneling as much telemetry into their walled garden as possible. (Yes, I’m looking at you, Microsoft.)

This is something I came up with this morning. It’s incomplete, but maybe I can finish it off at some point. I wonder if Cortana has a singing voice?

Partial lyrics for the ASIO/GCHQ/NSA song book

Aliasing variables in gcc

A little trick I just learned today. First, the scenario.

I have a driver for a USART port, the USART on the ATMega32U4 in fact. It uses a FIFO interface to represent the incoming and outgoing data.

I have a library that also uses a FIFO to represent the data to be sent and received on a USART.

I have an application that will configure the USART and pipe between that and the library.

Now, I could have each component implement its own FIFOs, and have the main application shovel data between them. That could work. But I don’t want to do this. I could have the user pass in a pointer to the FIFOs in initialisation functions for the USART driver and the library, but I don’t want to store the extra pointers or incur the additional overheads.

Turns out, you can define a symbol somewhere, then alias it to make two variables appear in the same place. This is done with the alias attribute, and it requires that the target is defined with the nocommon attribute.

In the USART driver, I’ve simply declared the FIFOs as extern entities. This tells the C compiler what to expect in terms of data type but does not define a location in memory. Within the driver, use the symbols as normal.

/* usart.h */

/*! FIFO buffer for USART receive data */
extern struct fifo_t usart_fifo_rx;

/*! FIFO buffer for USART transmit data */
extern struct fifo_t usart_fifo_tx;

/* usart.c */
static void usart_send_next() {
  /* Ready to send next byte */
  int16_t byte = fifo_read_one(&usart_fifo_tx);
  if (byte >= 0)
    UDR1 = byte;

ISR(USART1_RX_vect) {
  fifo_write_one(&usart_fifo_rx, UDR1);

I can do the same for the protocol library.

/* External FIFO to host UART */
extern struct fifo_t proto_host_uart_rx, proto_host_uart_tx;

/*! External FIFO to target UART */
extern struct fifo_t proto_target_uart_rx, proto_target_uart_tx;

Now how do I link the two? They go by different names. I create aliases, that’s how.

 * FIFO buffers for target communications.
static struct fifo_t target_fifo_rx __attribute__((nocommon));
static uint8_t target_fifo_rx_buffer[128];
extern struct fifo_t usart_fifo_rx __attribute__((alias ("target_fifo_rx")));
extern struct fifo_t proto_target_uart_rx __attribute__((alias ("target_fifo_rx")));

static struct fifo_t target_fifo_tx __attribute__((nocommon));
static uint8_t target_fifo_tx_buffer[128];
extern struct fifo_t usart_fifo_tx __attribute__((alias ("target_fifo_tx")));
extern struct fifo_t proto_target_uart_tx __attribute__((alias ("target_fifo_tx")));

 * FIFO buffers for host communications.
static struct fifo_t host_fifo_rx __attribute__((nocommon));
static uint8_t host_fifo_rx_buffer[128];
extern struct fifo_t proto_host_uart_rx __attribute__((alias ("host_fifo_rx")));
static struct fifo_t host_fifo_tx __attribute__((nocommon));
static uint8_t host_fifo_tx_buffer[128];
extern struct fifo_t proto_host_uart_tx __attribute__((alias ("host_fifo_tx")));

Now a quick check with nm should reveal these to all be at the same locations:

RC=0 stuartl@vk4msl-mb ~/projects/debugwire/firmware $ avr-nm leodebug.elf \
     | grep '\(proto_.*_uart_.x\|host_fifo_.x\|target_fifo_.x\)'
0080022c b host_fifo_rx
008001ac b host_fifo_rx_buffer
0080019c b host_fifo_tx
0080011c b host_fifo_tx_buffer
0080022c B proto_host_uart_rx
0080019c B proto_host_uart_tx
0080034c B proto_target_uart_rx
008002bc B proto_target_uart_tx
0080034c b target_fifo_rx
008002cc b target_fifo_rx_buffer
008002bc b target_fifo_tx
0080023c b target_fifo_tx_buffer

Solar Cluster: Debugging an ATTiny24A, fun and games with SPI

So, the debugging saga continues.

I’ve been busy the last few weeks so haven’t had much time to look at this, but I did get back to it today, and had some quality time with the Raspberry Pi AVR programmer and the ATTiny24A.

I ended up making a programming jig for the ATTiny24A in fact, so I could use it on a bare breadboard. I basically took a 14-pin DIP IC socket, soldered some header pins to it and tacked wires onto the pins that go to the ISP header and wired those out on a 2Ă—6 pin header. So the socket basically plugs straight into a breadboard and I’ve got a loose ISP header that the Pi plugs into.

All built with recovered parts from old motherboards. 🙂

I was able to connect nearly every pin to a LED, so could then see everything that was going on the SPI bus, and could use the remaining pins to indicate status. So I’m now starting to understand the USI device a bit better, but still struggling to get meaningful data.

A big challenge is synchronisation. SPI normally uses a chip-select pin, pulling this low can trigger the MCU to prepare for a command on SPI. The 6-pin ISP interface does not provide this however, so I have to kludge it. I find the Pi, when it stops transmitting, it lets go of SCK and it floats up ever so slightly, causing the MCU to think another pulse has started. Once that happens, the real games begin as the two are then out of step, never to recover.

I experimented today with using the 16-bit timer to count down a delay — basically it’s the Modbus/RTU approach, whereby if there’s a break in the comms, we reset.

Co-ordinating this though is a major headache.

I’ve looked into using debugWire. This apparently uses a UART-based protocol running over an open-drain connection through nRESET. My RPi-AVR programmer in theory could do it, but I’d need to bit-bang the UART as my reset GPIO is not one of the hardware UART pins. There is a driver out there.

The other option is to consider the LeoStick I mentioned in a previous post. This evening, I stumbled on the specs for the JTAGICE mkII protocol, so maybe I could develop my own debugger based on this protocol and use avarice? Sounds like a new project.

Another prospect is to say f### it and just use the LeoStick as my power controller. For that matter, the Adafruit Pro Trinket is cheap and uses a similar MCU. (ATMega328 instead of ATMega32U4.) Decisions, decisions…