Will the ICD-S40 work through a modem?

[Stimpy]

I'd like to do some remote debugging where both the PIC and the ICD-S40 are at a remote location and I'm sitting here at my PC. I've thought about connecting the ICD to my PC through a pair of external modems, but I'm not sure if this will work. The modems do have error correction and flow control so all the data is guaranteed to get through, but there will obviously be some delay. The question is, how much of a delay can the ICD program tolerate before it gives up, and can this be adjusted in any way?

Has anyone ever tried anything like this?

[Stimpy]

Well, I got it work (sort of).

The biggest problem is the way the ICD program communicates with the ICD-S40 device during startup. The DTR line on the serial port is connected to the reset pin on the device. When the device comes out of reset it sends a message to the program. When the program starts, the first thing it does is toggle DTR and wait for this message. This will obviously not work through a standard RS-232 dial-up modem since the DTR line doesn't pass through from the local modem to the remote one. There is a way around this though, but it requires two ICD-S40 devices:
- connect the remote ICD-S40 to the remote modem
- establish a connection between the local modem and the remote modem
- connect the local serial port to a spare ICD-S40
- start the ICD program
- disconnect the local serial port from the spare ICD-S40 and connect it to the local modem
- all regular ICD functions like load,verify,erase will now work on the remote ICD-S40 through the modems

This method will NOT work for running the debugger from inside the IDE since the IDE insists on doing a reset immediately followed by a load so there isn't enough time to swap the connectors. To get around this, here are two ideas:
- Build a small widget that connects between the PC and the local modem and transmits a fake startup message when the DTR line toggles.
- Use a specialty modem with a virtual COM driver that will pass the DTR line to the remote ICD. I've managed to find one of these so far (it's actually a cellular IP modem) and I think I'll try this approach next.

I'm still not sure if the ICD program will be able to handle the increased delays. Right now with the regular dial-up modems there's about 50-60 ms round-trip delay. With the addition of TCP/IP and GPRS cellular on top of that it may be in the hundreds of milliseconds. Even if it does work, it will be a bit slower than normal but still much faster than trying to run VNC or Remote Desktop over a modem.

[Stimpy]

Sadly, no luck with the cellular modem. The latency is just too high. By the time the reply from the ICD comes back, the program has already popped up an error message on the screen. Because the latency does vary greatly, sometimes I was able to get "Test ICD" or "Test Target" to work once or twice but never consistently enough to be useful.

I ended up writing my own loader that works though the serial port (and can tolerate infinitely long delays) and debugging will just need to be done through simple printf() statements along the way.

It would have been nice if there was some way to adjust the response timeout in the ICD program.