I do pretty much this same thing with PIC32 devices with the exception that this is performed with a bootloader and not an ICD. We program the bootloader into each device when it is manufactured and tested using an MPLAB-ICD3. We then use the bootloader for firmware upgrades.

The bootloader is a modified version of the one provided by Microchip. The modifications were to allow pass-through communications with the slave devices. The PC loader application also needed to be modified. Here is how it works:

1. Each device has two communications ports. One RS-232 port and one RS-485 port. The RS-232 port is usually only used by a master and all slaves may be programmed and configured via pass-through from that port. The slave devices may optionally be configured or programmed through their own RS-232 port.

2. Each device has an 8-position dip-switch which sets the device address. Each device also has a master/slave select dip-switch to define the master. You could use a pre-defined address to designate the master, but we had reasons to need the separate switch which are not related to this question.

3. Each command and data from the PC comes in the form of a packet. An address byte is added to the beginning of each packet to designate the target device. The address is set by a control on the window of the PC loader program.

4. All packets are acknowledged by the device that is addressed by the packet.

5. A master will use a packet if it matches it's own address and acknowledge that packet. The master will pass-through the packet to the RS-485 port if the address does not match it's own. The master will pass-through acknowledge messages from the RS-485 port to the PC.

6. A slave receiving a packet from the RS-485 port will use that packet and acknowledge it via the RS-485 port. If the packet is received from the RS-232 port (and the address matches), it will use and acknowledge the packet via that port.

7. Due to the additional time required for pass-through communications, timeouts in the PC loader application had to be extended. For additional reasons related to our product, we are not supporting the use of Ethernet-based virtual COM ports for firmware upgrades. If this were done, additional time would be needed. Most USB to serial adapters (using virtual COM port drivers) work fine with this method.

I do pretty much this same thing with PIC32 devices with the exception that this is performed with a bootloader and not an ICD. We program the bootloader into each device when it is manufactured and tested using an MPLAB-ICD3. We then use the bootloader for firmware upgrades.

The bootloader is a modified version of the one provided by Microchip. The modifications were to allow pass-through communications with the slave devices. The PC loader application also needed to be modified. Here is how it works:

1. Each device has two communications ports. One RS-232 port and one RS-485 port. The RS-232 port is usually only used by a master and all slaves may be programmed and configured via pass-through from that port. The slave devices may optionally be configured or programmed through their own RS-232 port.

2. Each device has an 8-position dip-switch which sets the device address. Each device also has a master/slave select dip-switch to define the master. You could use a pre-defined address to designate the master, but we had reasons to need the separate switch which are not related to this question.

3. Included in the communications protocols for all ports is a "Reset" command. This is used to reset the processor putting it into bootloader mode. The processor is in bootloader mode for a minimum of 0.5 seconds. This time is extended if bootloader packets are received (whether for it's device or for others). The PC loader application begins the bootload process by sending a global reset command to the master which will pass it on to the slaves.

4. Each command and data from the PC comes in the form of a packet. An address byte is added to the beginning of each packet to designate the target device. The address is set by a control on the window of the PC loader program.

5. All packets are acknowledged by the device that is addressed by the packet.

6. A master will use a packet if it matches it's own address and acknowledge that packet. The master will pass-through the packet to the RS-485 port if the address does not match it's own. The master will pass-through acknowledge messages from the RS-485 port to the PC.

7. A slave receiving a packet from the RS-485 port will use that packet and acknowledge it via the RS-485 port. If the packet is received from the RS-232 port (and the address matches), it will use and acknowledge the packet via that port.

8. Due to the additional time required for pass-through communications, timeouts in the PC loader application had to be extended. For additional reasons related to our product, we are not supporting the use of Ethernet-based virtual COM ports for firmware upgrades. If this were done, additional time would be needed. Most USB to serial adapters (using virtual COM port drivers) work fine with this method.