Current Version:

2.0

Released 10/24/2002

WinPSP 2.0 Documentation

I dislike unnecessarily long manuals, and most of WinPSP's functionality is easy enough for a typical hobbyist or engineer to figure out. I do, however, want to spend some time discussing how some of the more complex new features fit together. To do that, I'll describe a sample application that consists of two microcontrollers (a pair of 18F252s). The first microcontroller, known as the "master", has its USART connected through a typical MAX232 configuration to the PC. Only the RX and TX lines are run through; there is no hardware flow control. The second microcontroller, the "slave", shares a standard I2C bus with the master. Its MCLR (reset) pin is connected to the master's RA0 pin, and its RA2 I/O pin is connected to the master's RA2 pin. Both devices share a 10MHz oscillator and are bumped up to 40MHz via the HS-PLL oscillator configuration value. (If any of the above terminology is foreign to you, now would be a good time to consult the USART and MSSP sections of the 18FXX2 data sheet.) The schematic below details the demo circuit. You can click on it to view a larger version of it.


WinPSP and a Microchip PICSTART Plus are used to install boot loaders on each chip. The master is given a UART boot loader located at 0x7E00 configured to enter the boot loader on reset if RA1 is low. Its baud rate is set to 115,200bps. The slave is given an I2C boot loader located at 0x7E00 with an I2C address of 0x30. It will enter its boot loader on reset if RA2 is low. Based on the information so far, you can probably see that the master has been given complete control of the slave. It can control whether the slave runs its application or boot loader by setting or clearing its own RA2 output; it can reset the slave at any time by driving its RA0 output low and then high; and it can send commands to the slave's boot loader via I2C.

One piece of the puzzle that's missing is how to give the PC the ability to program the slave device. As described above, there is no direct connection between the PC and the slave. It is therefore necessary to be able to put the master in a mode where it relays boot loader commands to the slave. In fact, the master needs to be able to switch among three very distinct modes: application, boot loader, and "pass through". It shouldn't be necessary to press a button or change a DIP switch to switch modes; the PC should be able to issue commands over the serial interface to change the master's mode. These commands may vary quite a bit from application to application, but their functionality is essentially the same. A key point to remember is that it's the application that's in control most of the time; in addition to the task-specific commands that the application handles, it also handles two additional commands: the first command runs the master's boot loader; the second command forces the slave to reset into its own boot loader and then relays commands received from the PC to the slave's boot loader via the I2C bus.

The configuration just described is extremely useful when you need to locate an intelligent device remotely. An example would be a temperature and humidity sensor mounted on a wall. The sensor would continually send current environmental conditions to a PC via a serial link. From time to time it might become necessary to update the firmware of the sensor to change the frequency of its reports, etc. Using a boot loader and WinPSP, you can send new firmware to the sensor over the same serial link already connected to the device. And if you also throw WinPSP Remote into the mix, you can update that firmware using a PC that's not even connected to the sensor. WinPSP Remote can even notify the application that monitors the sensor when it starts and finishes updating the firmware. Obviously, the sensor example can be accomplished with a single microcontroller, but other applications require more facilities than are available on one chip, so it's important to include the I2C boot loader in this discussion.

The demo software, which can be found on the download page, consists of a simple Windows application and some firmware for the master PIC. C and assembly language versions of the firmware, identical in functionality, are included. The C code was written for the HiTech compiler, but can probably be adapted to other compilers fairly easily. All you need to build the assembly language version is Microchip's free MPLAB 5.70 development software.

The firmware is a relatively small application designed to communicate over a serial connection at 115,200bps. It has a simple text-based command language that recognizes the following case-insensitive commands:

  • H - The firmware will respond with the text "Hello, World!"
  • E - The firmware will echo back whatever text follows the command.
  • BL - Run the master's boot loader.
  • BP - Force the slave into its boot loader and enter pass-through mode.

    Commands and responses are terminated by a carriage return ('\r') and linefeed ('\n') pair. You can therefore communicate effectively with the master application using a standard terminal program such as Hyper Terminal (included with most versions of Windows). Communication settings should be 115,200bps, 8 data bits, 1 stop bit, and no parity. When you want to send new firmware to the master or slave, you can use Hyper Terminal to issue the appropriate "BL" or "BP" command, tell Hyper Terminal to disconnect, then use the Program command in WinPSP on a profile set up with the same communication settings.

    You can make the transition between application mode and programming mode much more seamless by using WinPSP Remote. Although WinPSP Remote can be used over the network, it's just as useful locally. You can teach it your application's commands for entering the master and slave boot loaders so that you never have to use a terminal program. The first step is to add entries to WinPSP Remote's device list for the master and slave chips. The settings for the master device should look like this:


    The command and response fields have the correct values for the demo firmware. You would change them as required for your own applications. These fields support the standard set of C string escapes, such as '\n' for newline, '\0' for a null character, and '\x04' to enter an arbitrary hexadecimal character value. Therefore, even if your application uses binary opcodes instead of text commands, you should be able to enter the correct representation of the command in WinPSP Remote.

    If you include a password in the Program section, WinPSP Remote will deny access to the device's boot loader without the correct password. MD5 encryption is used to avoid sending plain text passwords over the network. The On Hold string is an optional command that will be sent to any program currently communicating with the application when another program runs the device's boot loader. Similarly, the Off Hold command is sent once the device has been reset and is in application mode again. These notifications allow the software that interfaces with the device to suspend itself while the application is unavailable. If an application password is specified, connection to the device's application will be denied without the proper password.

    The slave's settings are as shown:


    When WinPSP Remote is used, you communicate with your firmware application using TCP/IP instead of directly through the COM port. WinPSP Remote listens on the IP port specified on its main screen and accepts connections to the devices on its list. It maps the device name to the associated COM port and keeps track of all connections to each device. If an application mode connection already exists for a device, WinPSP Remote will reject any subsequent attempts to connect to that application. However, it will allow a program mode connection for the same device, and it will suspend the application connection while that program connection is active.

    Obviously Hyper Terminal will not suffice for connecting to the demo application through WinPSP Remote. You should therefore use the Windows demo application provided, Demo.exe:


    Be sure to enter the appropriate Host and Port settings for your PC; the examples above won't work for you. If you don't know your computer's IP address, you can determine it by running ipconfig or winipcfg. Using the demo application you can send commands to the firmware and view the responses. If you use WinPSP to access the device's boot loader, you'll see the On Hold and Off Hold notifications appear in the same window. The Activity tab in WinPSP Remote can be used to keep an eye on your devices:


    The source code for the Windows demo application (which can be found in the WinPSP source distribution) illustrates how to create the TCP/IP connection to your firmware through WinPSP Remote. It also includes the MD5 encryption source code necessary to use application mode passwords.

    To configure WinPSP to access your device's program mode, create a new Programmer Profile that resembles the following:


    The "Network" radio button should be selected whenever you're going through WinPSP Remote, even if it's running on the same PC as WinPSP. In Network mode, the serial port and baud rate settings in WinPSP are ignored; what matters are the settings in WinPSP Remote for the device named in the Device input box. If you designated a program mode password in WinPSP Remote, you'll have to enter the same password in your WinPSP profile. Note that it is important to enable "Reset device after each operation". This setting ensures that the device you just programmed exits the boot loader and returns to application mode. Every time you initiate an operation in WinPSP, such as Blank Check, Program, or Read, WinPSPRemote sends the command it's been taught to put the device in boot loader mode. It expects to receive the designated response to that command. Obviously, if the device were left in boot loader mode by the previous operation, the application command wouldn't mean anything to the boot loader, and the response would never be received. Therefore, the reset after programming is important to the stability of your system. It's optional because there are other situations where it is desirable to leave the device in boot loader mode for several operations and then issue a manual reset through WinPSP (via Ctrl+R).

    The i2c.c/i2c.asm file in the demo firmware is the key to implementing pass through mode for I2C slave device programming. You can include that code in the master device firmware of any system that involves multiple microcontrollers. When there is more than one slave, it might be simplest to have an application command that allows you to specify the I2C address of the slave whose boot loader should be run.

    No slave application code is included in the demo package, since other than the I2C boot loader already installed, there's very little boilerplate code required for the slave; it can do whatever you want. The schematic discussed earlier calls for a few LEDs wired to the slave's PORTB I/O pins. You can send the slave a simple application to flash those LEDs. Obviously a real slave application would communicate with the master application as appropriate for the task to which it's devoted. If your slave device uses a boot loader located in high memory, remember to start your slave application with an I/O pin check to determine whether to continue the application or jump to the boot loader. For the demo circuit, the boot loader should be run if RA2 is low. Be sure to configure that pin as an input and also ensure that ADCON1 has the pin designated as digital I/O.