How to program the flash of multiple PIC controller

Question

We have 6 dsPIC33F (16bit) controllers in the system and the system is quite big and complicated. All controllers are located on different PCBs and connected to each other through RS485 bus.

1. First Pic controller (Master) is connected to PC and the rest of the controllers (5 slaves) are connected to Master using RS485 bus.
2. To program master dsPIC uses MPLAB-ICD programmer connected to PC.
3. Now To program Slave1 dsPIC we have to open the machine then locate the PCB and connect the programmer manually then program it.
4. Similarly we follow the same procedure one by one for all controller by removing the programmer and connecting to respective PCB to program the dsPIC.

I want to program all the controllers through software one by one from PC without removing the MPLAB_ICD when it is connected between the Master and PC by default. Or is there any other method through hardware or software to program all controllers one by one from PC itself without doing it manually?

What hardware/software changes do I have to make to program the dsPIC without opening the system?

Answer 1

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.