Adding A Debugger To A Teensy 3.5/3.6

May 1, 2017 by Inderpreet Singh 23 Comments

The Teensy is a powerful ARM-based development board with loads of features that can do fun stuff with USB as well. Like many dev boards, it uses a less powerful processor as an interface. Teensy designer [Paul Stoffregen] added a debug header to allow direct SWD JTAG access to the main chip, but the interface microcontroller has to be silenced for that to work, and the code to do so is still in progress.

Impatient, [Erich Styger] documents the changes he made to add support for the J-Link SWD protocol by removing the offending NXP Kinetis KL02Z that serves as the as the onboard interface and bootloader that helps the Arduino IDE talk to the K64F which is the main chip. After the KL02Z was removed, [Erich] populated the debug headers and then wired up the Segger J-Link to the board and tested it out with Eclipse, GDB, and standard SWD debug tools.

The end result is a Cortex M4F board that can work with standard tools at a third of the price of the Kinetis’ development board. [Paul Stoffregen] confirms that the debugging functionality will be added to the bootloader code soon but until then, a hardware hack is a working, if brutal, approach to debugging on the platform.

More information on the JTAG interface is available for the interested. And if Teensy isn’t your thing, you might consider an STM32-based development board.

Shmoocon 2016: Efficient Debugging For OS X

January 19, 2016 by Brian Benchoff 27 Comments

Developers love their macs, and if you look at the software that comes with it, it’s easy to see why. OS X is a very capable Unix-ey environment that usually comes on very capable hardware. There is one, huge, unbelievable shortcoming in OS X: the debugger sucks. GDB, the standard for every other platform, doesn’t come with OS X and Apple’s replacement, LLDB is very bad. After crashing Safari one too many times, [Brandon Edwards] and [Tyler Bohan] decided they needed their own debugger, so they built one, and presented their work at last weekend’s Shmoocon.

Building a proper tool starts with a survey of existing tools, and after determining that GDB was apparently uninstallable and LLDB sucked, their lit review took a turn for the more esoteric. Bit Slicer is what they landed on. It’s a ‘game trainer’ or something that allows people to modify memory. It sort of works like a debugger, but not really. VDB was another option, but again this was rough around the edges and didn’t really work.

The problems with the current OS X debuggers is that the tools used by debuggers don’t really exist. ptrace is neutered, and the system integrity protection in OS X El Capitan has introduced protected locations that can not be written to by root. Good luck modifying anything in /Applications if you have any recent Mac.

With the goal of an easy-to-use debugger that was readily scriptable, [Brandon] and [Tyler] decided to write their own debugger. They ended up writing the only debugger they’ve seen that is built around kqueue instead of ptrace. This allows the debugger to be non-invasive to the debugged process, inject code, and attach to multiple processes at once.

For anyone who has every stared blankly at the ‘where is GDB’ Stack Overflow answers, it’s a big deal. [Brandon] and [Tyler] have the beginnings of a very nice tool for a very nice machine.

Showing An AVR Programmer Who’s Boss

April 13, 2015 by Mike Szczys 25 Comments

[Bogdan] makes a good point. When you use a dev board you get programming, debugging, power sourcing, and usually a UART. When you go to the trouble of hooking up a programmer why don’t you get the same thing? Astutely, he points out that all you usually get with programmers is programming. So he set out to add features to the hardware he uses to program XMEGA.

The first part of the trick hinges on his use of PDI programming. This is slightly different from ISP programming. Both use a six-pin connector cable but with PDI two of these pins are unused. He took this opportunity to reroute the chip’s TX and RX pins through the cable, which now gives him an avenue to use a UART-to-USB adapter without adding any cables to his target board. Rather than add a second USB cable he rolled a USB hub into the mix. An LM1117 regulates the 5V USB rail down to 3.3V as a source for the target board.

The programmer being used is an Atmel ICE. As you might imagine he didn’t want to make permanent alterations to it. His modifications are all handled externally, with one IDC cable connecting the programmer to his added circuitry and another headed off to the target board. For now he’s jumpering RX/TX to the programming header but plans to route the signals on future PCBs.

Dual Port RAM Teaches An Old NES New Tricks

May 6, 2014 by Adam Fabio 11 Comments

nesDPR

[Andrew] is developing a game for the Nintendo Entertainment System (NES). Emulators are great for this, but [Andy] loves running on the real iron. To help, he’s created a dual port RAM interface for his NES. As the name implies, a dual port RAM is a memory with two separate data and address buses. The Cypress Semiconductor CY7C136 [Andy] used also includes arbitration logic to ensure that both ports don’t attempt to access the same memory cell and cause data corruption. In [Andy’s] case the NES was on one side, oblivious to the new hardware. On the other side of the dual port RAM, [Andy] installed an ATmega164 running his own custom firmware.

The new hardware gives [Andy] a live view of what’s going on in the NES’s memory. He added a live memory view/edit screen similar to the FCEUX emulator. The window runs on a PC while the game itself is running on an NES. [Andy] was even able to add rudimentary break and step features by connecting his circuit to the Non Maskable Interrupt (NMI) line of the NES. By holding the NMI asserted, the ATmega can essentially freeze the game in progress.

[Andy] has even used his circuit to teach the NES some new tricks. By reading the timer and score memory locations on Ice Hockey, he was able to create a scoreboard and goal light. Similar techniques were used to give Contra a muzzle flash light which puts Ambilight systems to shame.

We don’t know what [Andy] is planning next, but we hope it’s a source release so we can start hacking some some games ourselves!

Click past the break to see a couple of [Andy’s] Vine videos.

Continue reading “Dual Port RAM Teaches An Old NES New Tricks” →

Serial Monitor Without A PC

April 8, 2014 by Will Sweatman 18 Comments

serial01

A serial monitor is an easy way to debug your projects. As we step through code, it’s nice to see a “Hey! I’m working, moving to next thing!” across the monitor, and not so nice to see nothing – the result of a bug that needs debugging. This has always meant needing a PC loaded with your favorite serial terminal program close at hand.

Most of the time this is not an issue, because the PC is used to compile the code and program the project at hand. But what if you’re in the field, with a mission of fixing a headless system, and in need a serial monitor? Why lug around your PC when you can make your own External Serial Monitor!

[ARPix] built this fully functional serial monitor based on an Atmega328 and a 102 x 64 LCD display. While it doesn’t have a keyboard port like this microcontroller based serial terminal, tact switches allow access to the user interface to start and stop the reading and set the baud rate. The Atmega328 has 2K of SRAM, which is needed for the project. Apparently, 1K was not enough to handle all the data. All code, schematics and a very well done parts layout are available, making this sure to be your next weekend project!

Learning Assembly With A Web Based Assembler

March 23, 2014 by Nick Conn 47 Comments

AssemblyOnline Very few people know assembly. [Luto] seeks to make learning assembly just a little bit easier with his “fully functional web-based assembler development environment, including a real assembler, emulator and debugger.”

These days, you can be a microcontroller expert without knowing a thing about assembly. While you don’t NEED to know assembly, it actually can help you understand quite a bit about embedded programming and how your C code actually works. Writing a small part of your code in assembly can reduce code size and speed things up quite a bit. It also can result in some very cool projects, such as using Java to program microcontrollers.

With high quality example code, it is very easy to get started learning assembly. The emulator consists of a microcontroller with 32 registers, hooked up to three LEDs, two buttons, and a potentiometer. This is way better than painfully learning assembly on real hardware. Be sure to check out the online demo! Being able to step through each line of code and clearly see the result help make assembly easier to use and understand. It would be great to see this kind of tool widely adopted in engineering programs.

Have you used assembly in any of your projects? Let us know how it went and why you choose to use assembly

ARM Debugger For Nearly One Dollar

January 23, 2014 by Mike Szczys 58 Comments

Oh that title is so misleading. But if you squint your eyes and scratch your noggin it’s almost true. Thanks to the hard work of [Peter Lawrence] it is now possible to hack together an extremely inexpensive CMSIS-DAP ARM debugger.

Let’s talk about function and we’ll get back to cost later. CMSIS-DAP is a standard that gives you the kind of breakpoint control you expect from a proper debugger. In this case [Peter] implemented the standard using 4k words of space on a PIC 16F1454. This lets it talk to the debug port on ARM chips, and the bootloader (also written by him) doubles as a USB-to-UART bridge. Boom, done. OpenOCD (and a couple of other software packages) talks to the PIC and it talks to the ARM. Nice.

Back to the cost question. You can get a 16F1454 for nearly a dollar when you order in quantity. If you cut up an old USB cable, recycle some jumper wire, and already have power and decoupling on hand, you’re in business for nearly one dollar.