Developing Code for the ATtiny13A: Debug Setup

Where I illustrate how to debug code on the ATtiny13A on a Linux computer using the Microchip Snap, bloom and avr-gdb.

Sources

• gdb Resources
• Bloom
• Microchip SNAP

Introduction

The Microchip SNAP is a low-cost ($11) board which is great for debugging and uploading code to an AVR microcontroller. It is supported by tools such as avrdude and Bloom. While I had attempted to use the Microchip Snap before, I had not any luck. In my attempts to solve this problem, I ran across this link to Bloom: Enabling “AVR mode” on the MPLAB Snap. The article was great for two reasons, first, it explained why the Snap wasn’t working and provided detailed instructions as to how to fix the problem. Second, if you have a Linux computer, Bloom is a great debugging tool!!

This entry will describe how to setup and use avr-gdb with an ATtiny13A, along with Bloom.

Setup

These steps are required to setup a debugging workflow. I will make the assumption, you have a Linux computer (Raspberry Pi!) and have installed Bloom.

1. Connect to the ATtiny13A

Insert your ATtiny13A into your breadboard. You will then need to make connections to it via a cable from the SNAP.

Minimal Working Circuit

1. Connect VCC (pin 8) to your power supply (2.7-5.5V)
2. Connect GND (pin 4) to ground
3. Add 100nF decoupling capacitor between VCC and GND

ATtiny13A Pinout

ATtiny 13A Connections for SNAP SIL

Your wire color might be different, however, confirm the connections closely from the SIL (single in-line connector) and the DIP pins.

Here is my setup. I used a AVR ISP Breadboard Adapter from Adafruit, which made the connection from the Snap SIL connector to the ATtiny13A much easier. Using the adapter, I connect 6 wires from the Snap to the breadboard like this:

2. Edit the Makefile for gdb

In your Makefile, you will want to ensure your compile parameter includes “-Og -ggdb3” so the proper code for debugging is added to your file. I use the following line in my Makefile.

# use below to setup gdb and debugging
CFLAGS = -Og -ggdb3 -std=gnu99 -Wall -Wundef -Werror

3. Add a .gdbinit file

It helps to have a .gdbinit file, it eases the loading and can automate some of the more tedious setup process. I setup loading the main.elf file and connecting to the target as well as a compile-link-load command, called cll. (More on cll later.) Save it in your $home folder:

set confirm off
set pagination off
set history save on
set history size 10000
set history filename ~/.gdb_history

file main.elf
target remote :1442
load
set listsize 0
set tui compact-source on
tui focus cmd

define cll
make
load
l
refresh
end

define mrc
mon reset
continue
end

define td
tui disable
end

define te
tui enable
end

4. Setup Bloom as the gdb interface

Per the configuration guidance, you’ll need to create a yaml configuration file. The easiest approach is to follow the instructions and make minimal changes at the start. I have my Bloom yaml configuration file at the root of AVR_C.

# do this in your project folder
bloom init;

Here is my bloom.yaml file for the SNAP:

  snap_13a:
    shutdown_post_debug_session: true

    tool:
      name: "snap"
 
    target:
      name: "attiny13a"
      physical_interface: "debug_wire"
      hardware_breakpoints: true
      manage_dwen_fuse_bit: true

    server:
      name: "avr_gdb_rsp"
      ip_address: "127.0.0.1"
      port: 1442

	insight:
  	  enabled: true

Debugging Process

A simple overview is start bloom, start avr-gdb, begin to debug, edit the errors, reload and repeat! Bloom provides a complete full-cycle method to run-edit-reload a target, which is fantastic! Let’s begin.

1. Start bloom

You will want to start bloom before you start avr-gdb. Bloom doesn’t require a lot of attention, however, you will want to be able to view the window easily, as it will indicate if the connection with the target is broken. I typically start it in my first tab in my terminal program. Make sure you start bloom in your project folder, as it will need to find the bloom.json file.

bloom snap_13a # in project folder (in my case ~/Documents/AVR_C/)

2. Run avr-gdb

In the main window (in my second tab), preferably full-height, in the same folder as your makefile and source. You will need to have run make complete to have a loadable main.elf file prior t to starting avr-gdb.:

avr-gdb main.elf
# to begin running the program (c as in continue)
c 
# to stop execution
Ctrl-C
# to set a breakpoint, at a function name or set a lineno
br functionname | lineno
# to show values of variables etc
disp variablename

3. When you want to upload code

Ok, you’ve found a bug, edited your code and now you want to reload it on to the ATtiny13A… Do all of this in the comfortable confines of avr-gdb.

# Ctrl-C to stop the processor and return control to the console
(gdb) cll # this will compile-link-load your file back on to the ATtiny13A
(gdb) c # begin execution to determine if fix worked 

The cll command comes from the .gdbinit file and performs the following:

• make - recompiles necessary files to ensure the latest version
• load main.elf - the magic step where bloom loads the program on the ATtiny13A
• list - list the program again
• refresh - clean up tui display

Example Display

Large Version to see detail

This screenshot is of avr-gdb, immediately after executing the cll and c commands.

Screen Setup

When I’m debugging using avr-gdb/bloom, I will have two half-screen (vertical) windows open. On the left half of the screen, I have sublime text for editing the program. On the right half of the screen, I have my terminal program (ghostty), with two tabs, the one used most often shows avr-gdb, while the other tab is used to start bloom. My steps are the following, edit the code in sublime text, switch to avr-gdb and run cll which is a compile-link-load of main.c, then press c to start the program.

Happy Debugging!