Digi ConnectMe Notes

Digi provides a JTAG development kit (DK) for around $1500 US. The kit includes a development board, a JTAG ConnectMe module, a JTAG interface module, a CD with ThreadX, NetOS and MicroCross/GNU development tools, lots of cables, all the right power supplies, just everything you need to write ConnectMe applications. Except intelligence. You have to provide that. That fact was my first problem.

The DK came with a printed Programmer's Guide that told you how to hook up the wires, but not why. After reading that manual, and the Hardware Reference, it was not clear to me how the JTAG and the two serial ports were supposed to interact with the processor. Nor was it clear to me where the second serial port was coming from - the non-JTAG ConnectMe has only one.

As it turned out:

1. The ConnectMe module has a JTAG variant that is intended for use with this kit. The JTAG signals come out of the metal case on a little wing of circuit board material. So do the second serial port signals. You lose the second serial port when you go to the standard module.

2. The Programmer's Guide tells you how to line up the serial ports as stdin/stdout. It mentions the second serial port, but neglects to tell you that, in order to enable the second serial port, you have to change a Board Support Package (BSP) header file and recompile the BSP. I have the details somewhere, but they will probably change over time. Just be aware that it's a problem and ask Digi tech support before wasting time on it.

3. DO NOT use code that has the second serial port enabled on a non-JTAG ConnectMe (i.e. no second serial port). The BSP will hang while initializing the nonexistent port, and your ConnectMe will be TRASH (more on that later). I decided not to use the second serial port, since I hate having code that's different between the emulator and the target.

4. The JTAG interface takes over the ARM7 (NS7520) processor via debugging logic embedded in the ARM. When you load code through JTAG, you are writing the code to the processor's RAM. When you execute your code, you are forcing the processor to jump directly to your RAM based code. Once the JTAG pod takes over, no FLASH-based code is executed. That includes the boot loader as well as application code. The JTAG does not directly erase Flash, though you can load RAM based code that does so, e.g., sample project naftpapp.

5. The serial connections are not used to control the debug sessions. They come into play only when your RAM based application code is executing. The language in the Programmer's Guide implies otherwise. It makes more sense my way, but I was not sure what the truth was until I did some experiments.

6. The second serial connection is intended as a debug console for your debug session. You can line it up as stdin/stdout if you want, then do printf debugging as long as you're using the JTAG module. In fact, you can load your app onto the JTAG module's FLASH using naftpapp running in RAM, then reboot, and do printf debugging without the JTAG pod. If you want to.

Larry Martin
www.GlueLogix.com
Copyright (c) 2004 Larry Martin. All Rights reserved.