Firmware Installation

Note:

WISPs come programmed, right out of the box! Feel free to skip ahead to the Running the Reader tutorial!

However, they may not have the demo that you want (temperature, acceleration, etc.).

Or, you may want to develop your own application. If you want to learn these steps, please read on.

Step 0: Get the IDE

IAR Embedded Workbench Kickstart Edition MSP430 5.40 or lower is recommended. There is currently a compatibility issue with newer versions of IAR Embedded Workbench (version 5.50+). The code-size limited “kickstart” edition of this IDE is fine for most WISP users.

Code Composer Studio is also an option. This is a TI-provided IDE with no code size limit. You will have to do some amount of code modification to get things to build properly in Code Composer. See the guide at the bottom of this page for more details.

Step 1: Get the firmware

Go to the WISP Firmware page for the WISP hardware you're using and follow the directions for getting a copy of the firmware. (If you're using the 4.1DL WISP, the firmware page is here.)

Step 2: Set up the IAR Embedded Workbench Project and compile the firmware

The firmware installation program can be found here:

Start Menu\All Programs\Programming\IAR Systems\IAR Embedded Workbench KickStart for MSP430 V4\IAR Embedded Workbench

Now you need to create a IAR workspace and a new project. First do File → New → Workspace, then Project → Create New Project and select the Empty project template for the MSP430 toolchain. Supply a name for your projects settings file. Right click your project and add→ files and add in the firmware.

Before you can compile the firmware, there are some project options that need to be changed from their defaults. Right click the project name and select options.

On general options → target, change the device name to match the MCU your WISP hardware is using. (For the 4.1DL WISP, that's the MSP430F2132.)

(NOT SHOWN) Make sure that under the Language Tab C++ is selected:

Next, go to C/C++ compiler and enable the regvar settings for registers 4 and 5:

Next, go to Debugger and select the FET Debugger instead of the simulator:

Lastly, go to the FET Debugger tab and select the TI USB-IF connection with autodetect. (It doesn't matter if you're using the USB key debugger – use these settings anyway.)

Set the voltage to 2.2V at minimum. 2.5V is recommended. If you want to run the WISP on the debugger at 1.8V, you will need to do some specials steps (at the end of this page).

Save the new settings.

Now try compiling with a right-click of the project and picking Build All. (You may see more than one .c or .h file in the project hierarchy.) When the build is complete, you should see messages that look like this:

Congratulations, you've just compiled your first WISP firmware.

IAR tip #1: unexpected behavior when copying folders

If you copy a project folder, double check that you are editing the correct files. IAR automatically opens files from the original folder, not the new folder.

IAR tip #2: internal tool error message

You might see this error message: Tool Internal Error: Internal Error [any]: Unexpected Exception during compilation. The workaround is to close the workspace, go open some other workspace, clean and compile the code, close that workspace, now go back and open your original, problematic workspace, and clean and compile the code.

IAR tip #3: “Error[e46]: Undefined external “bits” referred in hw41_D41 …“

Remove the 'extern' modifier from the bits and dest declarations on lines 239 and 243

Step 3: Connect the debugger

The instructions for this step depend on whether you're using the FET debugger or the USB key debugger. Skip to whatever subsection is appropriate for you.

Step 3(A): Connecting the FET Debugger

I used a sharpie to mark the where the red stripe should line up. You can also tell by the JTAG connector and by the grey/white tone of the FET Plastic Casing.

Driver Note: If the drivers are not found automagically, they are in: C:\Program Files\IAR Systems\Embedded Workbench 5.0\430\drivers\TIUSBFET\WinXP

Step 3(b): Connecting the USB Key Debugger

Remove the cap on the USB connector. A flathead screwdriver does a good job of opening the plastic case (which we won't be needing again).

The WISP serial number (the white label) should face towards you. The “Texas Instruments” label on the USB Key Debugger should also face you.

My USB Key Debugger has 6 pins!?! Attach WISP in the center (one spare pin on each side).

Driver Note: If the drivers are not found automagically, they are in: C:\Program Files\IAR Systems\Embedded Workbench 5.0\430\drivers\TIUSBFET\WinXP

Step 4: Install the firmware on the WISP

Now deploy the firmware to the WISP with Control-D. It will copy the firmware to flash, and leave you in the debugger. Shift-Control-D to end the debugging session and physically disconnect the WISP from the debugger.

Note: When installing firmware using the USB Key Debugger you will receive the warning, “Chosen derivative (MSP430F2132) and actual hardware (MSP430F21x1) do not match. Continue to download?” You can safely ignore this message, and click Yes..

Note: If IAR stops responding after programming and before entering the debugger, go to options –> debugger and uncheck “Run to main.”

Something not working? Please read through WISP Troubleshooting before asking for help.

You are now ready to put the WISP in front of a reader and get back data.

Optional Step: Configure your WISP

The behavior of the WISP is configured in mywisp.h. The default settings are as follows:

WISP ID = 321

Application mode = Sensor data embedded in EPC

Sensor Type = Accelerometer (Quick sampling version)

If you want your WISP to have a unique ID or to use a sensor other than the accelerometer, you need to go through the 7-step configuration process outlined in mywisp.h (read the comments!). Please note that not all modes are fully supported. Typically, configuring the WISP in an unsupported mode should trigger build error(s).

Migrating the firmware to TI's Code Composer Essentials

The Kickstart edition of IAR Workbench is free, but has a 4K code size limit. TI's Code Compose Essentials (CCE) is free and has an 8K code size limit.

Unfortunately, each tool has it's own set of syntax idiosyncrasies, so it takes some doing to get the WISP code to work in CCE. The steps you need to take to migrate the firmware to CCE are listed below.

CCE needs a leading space for assembly instructions, but no leading space for labels. Why? As far as I can tell, because they were too lazy to parse for the ”:” to distinguish labels. For example: asm(“MOV R10, R11”); becomes asm(“ MOV R10, R11”);
regvar is the IAR way of reserving registers 4/5 for the user. We use this for the variables “bits” and “dest”. In CCE you just declare the variables normally, and use the get_R4_register()/set_R4_register() intrinsic functions. You'll need to make the changes wherever you use “bits” or “dest”.
(2) is tricky in the sendToReader function, as register 5 is accessed during the timing sensitive section of the code, and the CCE intrinsics have a different cycle count than their IAR alternatives.

bits = TRext;

needs to be replaced with

__set_R5_register(TRext);

asm(“ NOP”);

and

bits = numOfBits;

is replaced with

set_R5_register(numOfBits);

asm(“ NOP”);

If you are using Code Composer 4

A couple additional issues arise if you are using version 4 of Code Composer.

This version seems to use strict parsing, which means that declarations cannot be made after any executable statements in any given block. Because of this, there are a few places where you will get the following error: “declaration may not appear after executable statement in block”. To fix this, simply declare the variable in question before any executables in the affected block.
Code Composer 4 also does not seem to recognize the “#warning” directive, so an easy solution to this is to comment out any affected warning statements.