Intermittent JTAG with MaxV Device

[Altera_Forum]

I am fairly new into JTAG programming of devices. 

 I have a new design with a MaxV CPLD. The first run of prototypes we had forgot the pullup/down resistors in the JTAG chain. After adding those, everything was fine.  I now have a new board (only one, no comparison to another new board) where the MaxV does not always want to be programmed.  1. Programming progress stops at various locations into the programming process 2. After power cycling the board SOMETIMES the programming is working. When it is working after a power cycle, it is working consistently until the next power cycle. 3. I have now ended up in a situation where it always seems to fail at 56% down the programming cycle. 4. Erase is always successful but the blank check fails if I do those individually. 5. The old board still programs fine. 6. I checked all the connections from the 10pin connector to the CPLD, everything checks out fine. 7. The CPLD power supply is switched electronically. The power on is quite soft to limit the power surge loading all decoupling Cs, could this bring the JTAG interface into an unknown state? After a successful programming session, the CPLD seems to start consistently with the electronic on/off.  Could this have anything to do with the decoupling of the device supply nets? The MaxV chip is from another production date, could that have any potential impact?  Thanks

[Altera_Forum]

Failure in the middle of JTAG programming doesn't sound like unknown initial JTAG state. It's rather a problem of JTAG signal quality or possibly bad power supply. If no external signals are present in the cicruit that may interfer with JTAG action, I would primarly think of distorted JTAG signals, e.g. ringing SCK.

[Altera_Forum]

I agree with FvM, you are getting success for short JTAG commands that really have no long data transfers (.e.g device ID and erase). The verify/blank check and program steps require lots of data traffic across the JTAG connection - failure of these with success in other non-data intensive commands points to signal integrity issue. You should scope the TCK signal for integrity during the program or blankcheck actions. Sometimes, the capacitance of the probe will clean the TCK signal and you will see these program actions passing when you try to measure them (Heisenberg at his best). Regardless, first step is probing TCK.

[Altera_Forum]

Unlike FPGA config data, the MAX programming data, pof, will chopped to 2bytes and will sent to the cable. 

So I believe the data has been very small. I agree, it's more likely signal quality issue.

[Altera_Forum]

Thanks for the replies. Issue was finally solved.  

 1. VCCINT was running on 3.3V instead of 1.8V (my mistake, but it was not causing the JTAG issue, strangely enough the CPLD appeared to run normally @ VCCINT=3.3V) 2. A logic level RS232 device was connected. The Tx of this device was running at +5V levels. There is a filter in this line that weakens this signal. Disconnecting this device brought JTAG performance back to normal. Funny that a relatively weak TTL level signal can have this effect and that it took me so long to figure this relationship out.  JW