Originally released on the Nintendo 64 in 2001, Animal Crossing was the first entry into what has become a massively successful franchise. But while the game has appeared on more modern Nintendo consoles, most recently Android and iOS, the version released on the GameCube holds a special place in many fan’s hearts. The GameCube version was the first time those outside of Japan got a taste of the unique community simulation offered by Animal Crossing, and maintains a following nearly 20 years after its release.
[James] starts by using the debugger provided by the Dolphin GameCube emulator to poke around and figure out exactly what flags need to be modified to activate the debug mode. This leads to a few interesting finds, such as being able to pop up a performance monitor graph and some build info. Eventually he finds the proper incantation to bring up a functional debug display in the game, but there was still the mystery of how you do it on the real hardware with a retail copy of the game.
It wouldn’t be unreasonable to think that some special dongle or development version of the GameCube would be required to kick the game into debug mode. But through careful examination of the code path, [James] was able to figure out that hitting a specific combination of buttons on the controller was all that was required to use the debug mode on the stock game. Once the debug mode is started, a controller plugged into the second port allows the user to navigate through options and perform tasks. Not everything is currently understood, but some progress has been made, such as figuring out how to add items to your inventory.
Anyone who slings code for a living knows the feeling all too well: your code is running fine and dandy one minute, and the next minute is throwing exceptions. You’d swear on a stack of O’Reilly books that you didn’t change anything, but your program stubbornly refuses to agree. Stumped, you turn to the only one who understands you and pour your heart out to a little yellow rubber duck.
When it comes to debugging tools, this digital replacement for the duck on your desk might be even more helpful. Rubber duck decoding, where actually explaining aloud to an inanimate object how you think the code should run, really works. It’s basically a way to get you to see the mistake you made by explaining it to yourself; the duck or whatever – personally, I use a stuffed pig– is just along for the ride. [platisd] took the idea a step further and made his debugging buddy, which he dubs the “Dialectic Ball,” in the form of a Magic 8-Ball fortune teller. A 3D-printed shell has an ATtiny84, an accelerometer, and an LCD screen. To use it, you state your problem, shake it, and read the random suggestion that pops up. The list has some obvious suggestions, like adding diagnostic print statements or refactoring. Some tips are more personal, like talking to your local guru or getting a cup of coffee to get things going again. The list can be customized for your way of thinking. If nothing else, it’ll be a conversation piece on your desk.
Have an ESP8266 development board such as the NodeMCU or Wemos D1? You’re currently reading Hackaday, so probably. Got an Android device kicking around? Also seems fairly likely. In that case, you should check out ESP8266 Loader by [Bluino Electronics]. This recently released application lets you not only flash new binaries to any ESP8266 board using the FTDI, PL2303, CH34X and CP210X USB chipsets, but also offers a serial monitor for debugging on the go.
You’ll need a USB OTG cable to get your ESP board jacked in to your Android device, but you don’t need root or even to fiddle with the development settings. Here at the Hackaday R&D Dungeon we had somewhat mixed success getting a random selection of Android devices to work fully; all of the ones tried could at least open the serial monitor and read what a pre-programmed ESP was saying, but not all of them could successfully program a board.
Even on the devices where programming worked, it was slow. Just a basic LED blinking Sketch took long enough to write to our test Wemos D1 Mini that we contemplated getting a snack. But still, it shows a lot of promise for managing devices in the field, especially if you don’t have over the air update enabled in your code.
We especially liked that ESP8266 Loader helpfully downloaded a bunch of example binaries, many of which could be of practical use. There are programs for toggling the different GPIO pins on the board, creating Wi-Fi access points, and even a basic web server. With these in hand, you could actually do some testing and diagnostic work right from your mobile device.
Anyone who’s ever written more than a dozen or so lines of code knows that debugging is a part of life in our world. Anyone who’s written code for microcontrollers knows that physical debugging is a part of our life as well. Atmel processors use a serial communications protocol called debugWire, which is a simpler version of JTAG and allows full read/write access to all registers and allows one to single step, break, etc. [Nerd Ralph], a prominent fixture here at Hackaday has dug into the AVR debugWire protocol and enlightened us with some valuable information.
While the protocol side of debugWire is a mostly-solved problem, the physical layer was giving him trouble. He started with a diode, and then went through a couple resistors and other components to interface with the debugWire pin on the AVR microcontroller, doing most of the troubleshooting work so now you don’t have to. He notes that interface components might need to be tailored to specific USB-TTL adapters, so keep that in mind if you care to delve into working with debugWire yourself.
We’re no strangers to debugging techniques here at Hackaday. As always, be sure to let us know if you run across any new techniques or try anything new yourself!
Debugging with printf is something [StorePeter] has always found super handy, and as a result he’s always been interested in tweaking the process for improvements. This kind of debugging usually has microcontrollers sending messages over a serial port, but in embedded development there isn’t always a hardware UART, or it might already be in use. His preferred method of avoiding those problems is to use a USB to Serial adapter and bit-bang the serial on the microcontroller side. It was during this process that it occurred to [StorePeter] that there was a lot of streamlining he could be doing, and thanks to serial terminal programs that support arbitrary baud rates, he’s reliably sending debug messages over serial at 5.3 Mbit/sec, or 5333333 Baud. His code is available for download from his site, and works perfectly in the Arduino IDE.
The whole thing consists of some simple, easily ported code to implement a bare minimum bit-banged serial communication. This is output only, no feedback, and timing consists of just sending bits as quickly as the CPU can handle, leaving it up to the USB Serial adapter and rest of the world to handle whatever that speed turns out to be. On a 16 MHz AVR, transmitting one bit can be done in three instructions, which comes out to about 5333333 baud or roughly 5.3 Mbit/sec. Set a terminal program to 5333333 baud, and you can get a “Hello world” in about 20 microseconds compared to 1 millisecond at 115200 baud.
Anyone who has worked with a microcontroller is familiar with using printf as a makeshift debugger. This method is called tracing and it comes with the limitation that it uses up a UART peripheral. Believe it or not, there are 8051 variants out there that come with only one serial block and you are out of luck if your application needs it to communicate with another device.
[Jay Carlson] has a method by which he can piggyback these trace messages over an on-chip debugger. Though the newer ARM Cortex-M software debugger already has this facility but [Jay Carlson]’s hack is designed to work with the SiLabs EFM8 controllers. The idea is to write these debug messages to a predefined location in the RAM which the debugger can access anyway. His application polls a certain area of the memory and when it finds valid information, it reads the data and spits it out into a dedicated window. It’s using the debugger as a makeshift printf!
[Jay Carlson] used slab8051.dll interface and put together a C# program and GUI that works alongside the SiLab’s IDE. The code is available on GitHub for you to check out if you are working the EFM8 and need a helping hand. The idea is quite simple and can be ported to other controllers in a multitude of ways like the MSP430 perhaps. For those of you who like the Teensy, you might want to take a look at adding debugger support to the Teensy 3.5/3.6.
Wouldn’t it be great if there were just one standard for attaching to, programming, and debugging hardware? If you could just plug in and everything would just work? Dream on, dreamer! But of course we hobbyists aren’t the only people to suffer from multiple standards. Industry has the same problems, writ large. In response to the proliferation of smart devices — microcontrollers, sensors, and their friends — on any given PCB makes it difficult to test them all, much less their function as a system.
The Joint Test Action Group (JTAG) got together in the mid-80s to make automated testing of circuit boards a standardized process. A JTAG port can be found on almost any piece of consumer electronics with enough brains to warrant it, and it’s also a tremendously useful entry point for debugging your own work and hacking into other’s. You’re going to need to use JTAG someday.
Implemented right, it’s a very cool system that lets you test any compliant IC on the board all from a single connector. It’s mostly used by hackers for its ability to run and halt individual processors, and put them in debugging modes, inspecting their memory states, etc. Essentially every microcontroller responds to JTAG commands, and it’s an incredibly widespread and powerful standard. A victory for rationality and standardization!
The connector pinout was, of course, left up to the manufacturer. The horror!
In principle, JTAG uses five signal lines. They form a chain starting at the debugger, where one device’s output is the next device’s input, until the result is returned back to the debugger.
Test Data In (TDI) is the input from the debugger
Test Data Out (TDO) is the return end of the chain
Test Clock (TCK) clocks this data along synchronously, similarly to SPI
Test Mode Select (TMS) lets the devices know that they’re being debugged — it’s a global chip select
Test Reset (TRST) is an optional signal that resets all devices in the chain