There appears to be something broken in the CPLD code, not sure. With nCS0 == HI and MODE3 == HI, FLASH_nCS incorrectly asserts a LO.

Somehow, the CPLD asserts the enable to the Flash chipselect. This is really odd.

I've been using the 7a400 for some time and I've never had a problem with the VPEN bit being cleared. Perhaps you would share some details of you application that will shed light on the problem.

Tom W.,
Could it be that you are not doing 16 bit accesses to this area when writing to the Flash Register on the CPLD? The CPLD is in a 16 bit area.

-Mike A.

Good call Mike A, that's my guess.

Tom, can you confirm or deny this?

Thanks,
--mikee

No, I am definately doing an 8 bit access, not a 16 / 32 bit. I'm accessing the board via JTAG at this point when the problem shows up.

I have to dig a bit deeper into this. One theory that I have is that the CPLD is being put into JTAG mode itself due to activity on the CPU's JTAG. The JTAG software I'm using to connect to the board uses a "discovery" routine where it clocks the JTAG line like mad to see if the JTAG has other devices daisy-chained to TDI & TDO.

I'll work with some simpler JTAG routines to see if I can locate the problem. I did a half-hearted attempt to clock the JTAG of the CPLD to put it back into a TEST/RUN state, but I may not have clocked it enough to recognize the instruction.

Another possibility could be that CPLD may be bad, or due to activity on the JTAG, there is noise being injected into the supply bus and throwing the CPLD into an unknown state.

This is an important issue to resolve as the JTAG I'm using is an inexpensive wiggler. For my end-customer, it is of value to them as their technicians would use the inexpensive interface to board level repair, and testing, on the custom mainboard I'm designing.