This page documents tips and tricks for debugging WISP firmware. Dan Yeager, Richa Prasad, and Polly Powledge maintain this page.

Introduction

Designing and debugging WISP firmware is a unique challenge. Software developers for embedded systems spend a lot of time considering power envelopes and battery life, and they have well-understood techniques like duty-cycling and shutting off power to peripherals that they can use to extend the time to charge. But they also operate in predictable power source environments: they just run, until they don't.

In contrast, the WISP (and indeed any power-harvesting device) operates in completely unpredictable power environments. Here is a sample scenario: it has enough power to run but not operate at its full capacity, then it can run at full capacity, then it can't really operate at all for a while but retains RAM while it stores power, then it can operate at full capacity, then it needs to store more power for a while, then it shuts down completely, then it has enough power to boot but not enough to operate, then it has enough power to operate in a degraded mode, and so on. As you would imagine, the challenges of designing and testing an embedded device in this environment are considerable.

Getting Started

First take a look through the HW How To - FAQ. Then peruse through this page.

See Also

For hardware issues, see Debugging Hardware.
For RF Front End issues, see WISP RF FE Measurement Procedures

Question: How to I find and probe a particular signal?

Answer: Take a look at the schematic and annotated pcb layout on the WISP 4.1 DL hardware page. If you need more help, post a request on the Discussion page!

Tip #1: Read up on MSP430 clocks and low power modes

The MSP's clock and power mode systems are very configurable, and you can do a lot with them. But it's also pretty easy to get yourself all tangled up, too. It's worth some time to sit down and make sure you really understand how they work.

Tip #2: Use JTAG

Sure, JTAG supplies power to the WISP, and that messes up everything. But I still use it to debug code fragments that I know will run always run in active mode. For example, when I develop new sensor code, I do it as a small test program running under JTAG, with the receive clock settings copied in. Once I have this code fine-tuned, I can copy it into the sensor.h for the real WISP firmware.

Tip #3: The oscilloscope is your friend

I use unused i/o pins to tell me when I'm in sleep mode, and when I'm in active mode, and to identify when I'm processing specific kinds of packets. I probe the receive and transmit ports to help me debug packet and bit timing issues. I probe Vout to tell me where the power hog code is in my firmware.

Tip #4: Compare your device to a device that's working

I find that a lot of WISP development time is spent on fine-tuning the timing. Even apparently small variations in device clock outputs can make a WISP's response bits invisible. And different readers (and even different firmware versions on the same reader) can expect responses in tight time periods, and reject responses that arrive outside those periods. One way to shorten this kind of development is to probe a WISP or other RFID tag that's working alongside your in-development device, and then make your in-development device mimic the device that's working.

Tip #5: Use another MCU to simulate the voltage supervisor and exercise the power management code

At one point, I had a hairy race condition in the power management code, where I found myself in LPM4 with no interrupts enabled. I would come up with some hypothesis about why this was happening and code up a fix. Then I'd put the WISP in a marginal position that would flip the power management code on and off, and then wait, wait, and wait some more for the race condition to trigger. I was getting nowhere.

So I took a spare MCU and programmed it to fire an i/o pin repeatedly. I wired that pin to a spare i/o pin on the WISP, and redefined that pin as the voltage supervisor interrupt pin. I put the second MCU on an external 1.8v power supply and attached the debugger to the WISP, setting it at 1.8v too. I added some code just before the LPM4 to detect if interrupts were enabled and fire a breakpoint if this was false. After a while, the breakpoint fired and I had a complete stack trace that told me how I had gotten into this state.

No, this approach doesn't truly test how your firmware works as it drops below the voltage supervisor level. But it does let you use JTAG debugging to step through your power management code.



Tip #6: Running WISP at 1.8V on the debugger


If you want to run WISP at its native voltage on the debugger (1.8V), you will first need to program the wisp at a proper voltage (ex, 2.5V), and then change to a different mode in IAR.

This different mode is called "attach to running target" and allows the debugger to run the microcontroller without loading firmware. This is necessary because the debugger would corrupt the MCU firmware by trying to program at 1.8V. These options are in the project options under "FET Debugger."






The last modification was made by - yeagerd yeagerd on Sep 22, 2010 5:05 pm