For the most reliable operation you will probably want to load your application in flash memory. That way, your application won't be dependent on the Lithium battery. Obviously, your code would need to be written to tolerate the loss of the NVRAM file system and any of its data. Dallas has an application note on a high speed DS80C400 system which does not use NVRAM: http://pdfserv.maxim-ic.com/an/en/app615.pdf

You can add your application to slush so that you still have the command shell, ftp and telnet support, all in flash.

It's possible to do a remote update of TStik using Netboot. We use this on the assembly line to test "virgin" TStiks, which have no system or application installed. But you can also use Netboot to load an application into a TStik which already contains system and/or application code. One of our OEM customers does this, in part since they are selling a service which runs on TStik. Every time a customer's system boots up, it only loads the application if they have paid their bills, and then it ensures that every current customer is running the latest version of the application.

Another option is to just upload a new *servlet* (or several new servlets) rather than a whole new application. Tynamo supports this now. Tynamo is a web server and servlet 2.2 container written by Shawn Silverman. It can be downloaded at http://tynamo.qindesign.com/

It really works and we're using it. If you really want all our code for doing this, rather than creating your own, and want support to go with it, contact us with a credit card number and for $500 it's yours.

If you are up to rolling your own, start by reading the Dallas document NETWORK BOOT and you will also find information in the DS80C400 user guide, an excerpt here.

Tilt400.Pro supports netboot by providing a Dallas 1-Wire device (U14, DS2433) to hold the required netboot information.

One tricky bit is if you already have a valid user app in flash, and the netboot pin is de-asserted (by closing TStik paste jumper JP2) -- then NetBoot won't have a reason to load anything new. You have to either 1) invalidate the user flash app, then reboot or 2) enter a serial0 "N" character in order to branch to Netboot when the TINI ROM bootloader starts up. You can invalidate the flash app and reboot with the TININet.Netboot() method (see the TINI 1.15 javadocs). We've actually thought about a simple 'dongle' for serial0 which could enter the "N" character and we plan to add that to our manufacturing and service test fixture. If you open the paste jumper, then TStik will Netboot *every* time on startup - see further comments below.

TStik is built with P1.7, the serial loader pin, unconnected, so it is by default pulled high after a reset. Therefore, the serial loader will attempt to autobaud serial0 on every reset. If a 0x0d character (carriage return) is available then the serial loader will start and emit a banner message on serial0. If the loader then receives a 'N' character, Netboot will start, regardless of the state of JP2. There's a good flow chart in the Dallas Network Boot app note which describes this quite clearly.

Use the Solar Winds TFTP Server which works well but only supports a single connection. This is the TFTP server we used for a couple of years. If you need to support multiple simultaneous TFTP connections, use TFTPD32 by Philippe Jounin. We have tested it with four simultaneous connections and it works very well. Installation is simple, but read the instructions first. We have switched over to TFTPD32 for testing RoHS TStik, 4-up, and so far, are very happy with it.

Paste jumper JP2 must be open to enable automatic netboot on TStik (refer to the TStik Quick Reference for the location of JP2). TINI on the 80C400 will only auto-Netboot at 10 MBits when sensing the Netboot signal, so remove CFG2. We remove all three CFG jumpers when we netboot. See the TStik Quick Reference for ethernet jumper details. This limit doesn't apply when you are using the serial interface to send the loader an "N" character - then you can Netboot at 100BaseT speeds.

When TStik attempts to netboot, the contents of the NVRAM file system (including all your data) is flushed. Your IP configuration will be lost unless you have committed it to flash. If TStik can't netboot then it will attempt to run a valid application in flash (remember, NVRAM and its apps and data have already been flushed).

Still having trouble? Use ethereal to capture the ethernet packets during Netboot and see who's not doing the right thing.