[Springuin] just posted a tutorial about debugging MSP430 projects using Eclipse. He read our feature about debugging under IAR, a proprietary IDE which TI offers as a code-limited freebie with the TI Launchpad. In that writeup we wondered if anyone would put together a tutorial using open source tools like DDD and GDB to make debugging easier for those that choose to use operating systems other than Windows. Even though he didn’t directly use those particular packages, this should work just as well.
Eclipse is a popular IDE for many different languages like C, C++, Java, and others. We’ve already seen it used to develop for the TI Evalbot on Linux systems. [Springuin] is using the Java-based IDE on a Windows system, and this is the first time we recall seeing directions on using an open-source alternative for programming with the TI Launchpad under Windows. That being said, the only real Windows specific parts are the steps necessary for communicating with the programmer. Since this method uses MSP-GCC and msp430-gdbproxy, it should be easy to do this under Linux as well. Use our tutorial to set up those tools if you haven’t already, then follow this one for a setting up and debugging in the Eclipse environment.
Looks like some hardware enthusiasts have worked out a method to enable debug mode within AMD processors. The original site isn’t loading for us, but the text has been mirrored in this comment. Getting the chip into debug mode requires access passwords on four control registers. We’ve read through the writeup and it means very little to us but we didn’t pull out a datasheet to help make sense of the registers being manipulated. It shouldn’t be hard to find an old AMD system to try this out on. We’d love to hear about anything you do with this debug system.
[Dave] poked around inside of an IM-ME wireless toy and compiled his findings. He read about the device when we covered it in November and picked up a couple to see what he could do. He patched into the debug port in the CC1110 processor and enabled it by performing a chip erase. He then began mapping out how the processor connects and communicates with the qwerty keyboard, the wireless radio, and the LCD screen. The board is full of test points which make the hardware easy to access. [Dave’s] experiments show that this hackable device is full of potential so let’s see what you can do!
[Travis Goodspeed] took an in-depth look at the debugging protocols for some ZigBee chips and posted his findings. In particular he’s looking at the CC2430 System-on-chip. These chips have a debugging protocol that is not hard to implement if you know what you’re doing. Certainly his tips make it easier for the rest of us. Don’t miss the info about reading from, writing to, and overcoming security of this hardware.
simavr is a software simulator for the AVR line of microcontrollers. You might be asking why anyone would write this sort of thing considering the simulator provided with AVR Studio is a wonderful tool? Well, a lot of folks don’t run Windows and don’t wish to use that development environment even if Wine or Virtualbox could make it happen.
We haven’t tried it out ourselves yet. There is a discussion thread going that reports some positive results of using simavr with GDB and AVR Eclipse. It’s a new package, but so far it seems to have put its best foot forward. Currently there is support for ATtiny25/45/85, ATtiny13, ATmega48/88/168, andATmega164/324/644 chips. Several of the common on-chip peripherals are already supported with the others on the way.
Have you tried it out? Let us know what you think in the comments.
Have you always wished that you could develop games for the Super Nintendo but couldn’t because you were only 4 years old when it was released in 1990? Here’s a second chance. [Max] and his team have created a SNES developer’s cartridge that allows you to load your own code, run it on the SNES, and debug as needed. At its core is an Atmel AVR ATmega644 that is running a boot loader, allowing for firmware updates via USB. Once the system is powered on, ROM code is sent over USB to the 16 megabits of onboard SRAM. A debug terminal can be connected with an RS232 converter, providing status information and allowing some register manipulation.
We can believe there are a few hardcore SNES fans out there who will take the time to write custom code. We could also see this being used for the purposes of SNES sythesized music. But is there a wide demand for this type of hardware? If you’ve ever looked into developing for the SNES, let us know in the comments.
Our own [Anthony Lineberry] has written up his experience participating in the 2008 Malware Challenge as part of his work for Flexilis. The contest involved taking a piece of provided malware, doing a thorough analysis of its behavior, and reporting the results. This wasn’t just to test the chops of the researchers, but also to demonstrate to network/system administrators how they could get into malware analysis themselves.
[Anthony] gives a good overview of how he created his entry (a more detailed PDF is here). First, he unpacked the malware using Ollydbg. Packers are used to obfuscate the actual malware code so that it’s harder for antivirus to pick it up. After taking a good look at the assembly, he executed the code. He used Wireshark to monitor the network traffic and determine what URL the malware was trying to reach. He changed the hostname to point at an IRC server he controlled. Eventually he would be able to issue botnet control commands directly to the malware. We look forward to seeing what next year’s contest will bring.