Thanks for the response.
I have to say in defense, and I can only speak for myself, that my anti-static precautions are second to none. I also fully understand the nature of the failure on my modules.
With the programming cable connected, the SMODE pins are held high. This causes the rabbit processor to enter the cold boot, via ASYNCH Serial on Port A, at 2400 Baud. Then instructions are sent to the processor as triplets - MSB, LSB of address, followed by value. If the Highest bit of the MSB is set then the address is interpreted as an internal register address.
When I scope out the serial port, the reset and SMODE and STATUS lines I can see DC trying to toggle the STATUS line, but the status line does not respond.
This means that either the status line has gone bad, or the processor has not entered the hardware boot loader. I doubt very much that it is the status line going bad, since if you skip the processor verification it still does not work, and the status line is only used by the processor verification.
Now, the firmware which is still on board from previous successful programming cycles still runs perfectly, and (in my case) as it happens contains a full hardware test routine.
Every single parallel port, and serial port on the device is working perfectly.
(Including serial port A)
If the problem was caused by ESD damage, what are the chances that each module would die in exactly the same way? That must be millions to one against.
My own guess is that somehow the clock for serial port a is changed and the boot loader does not recognize the triplets being sent at 2400 - or serial port A can not be initialized by some other problem.
Following on, if you disable processor verification in DC, it will skip the toggling of the status line, and go straight to loading the initial loader - basically it’s working blind at that point as there is no feedback from the processor until it jumps to 6000 and starts the new loader. That fails, therefore the triplets being sent are not working.
I definitely do not think this is an ESD issue. I think there is some set of instructions that can prevent the processor going into the boot loader, or prevent serial port A working properly in the boot loader.
In my case I suspect that the modules tend to die when a compile error occurs. I believe the programming process goes something like this… detect processor, load initial loader, get processor ID, Flash Configuration etc, compile libs and program, then send compiled program to the device.
I suspect that if a compile error occurs, then DC leaves the processor in some kind of state that cannot be recovered from. But this is pure speculation at this point.
So, in summary, I do not think it is ESD damage, as hardware test prove that everything still works. The programming cable still resets the device, still holds the SMODE lines high, and you can ignore the status line by unticking ‘enable processor verification’ - there’s nothing else to have been zapped!