Spartan® Family FPGAs

[arnelln]

OK, first some background.

I have a board that has been designed to take either a XC6SLX75T or a XC6SLX45T, the device is configured using a quad SPI device (Winbond W25Q64).  Also on the board is a processor module, and a watchdog/reset chip.  The reset output goes to both the CPU and FPGA, the reset is active high.

The board powers up and boots OK when the SPI flash is empty, it is also OK when the SPI flash has the configuration for the wrong device.  The problem I am seeing is that if the SPI flash has the correct configuration, but has got corrupt some how (powerfail during programming of flash etc) then the reset line is being held at just over 1V and this is holding the processor in reset.

So I am just trying to find out why the FPGA I/O behaves differently when configuration fails on CRC as opposed to failing on synchronisation or device ID?

The bitstream is generated with the CRC check enabled, unused IOB pins are set to float, and HSWAPEN pin is tied high.

Thanks in advance

[gszakacs]

What pin are you using for the reset input?  If it is a dual-purpose pin (like INIT_B) then it could

retain its configuration-time function when the configuration fails.

-- Gabor

[arnelln]

---

gszakacs wrote:

What pin are you using for the reset input?  If it is a dual-purpose pin (like INIT_B) then it could

retain its configuration-time function when the configuration fails.

-- Gabor

---

The reset is on pin A4 of the CSG484 package which is listed as IO_L1N_VREF_0 in the pin description.

[gszakacs]

It might help to hook up the JTAG cable to Impact and read the device status after the board

comes up in the failure mode (Debug --> Read Device Status).  You can then see the state of

the internal configuration logic, which is harder to determine on a board that uses dual-purpose

pins as I/O.  This allows you to make sure that the device indeed failed configuration and if

so if it was due to CRC error.  Normally, I/O's should not start to drive if configuration fails.

Is it possible that there is another path to the reset signal besides the reset input of the

FPGA?  For example a power supply monitor that gets triggered by low voltage.

Also the pin you're using for reset is a Vref pin.  Is it possible you have inadvertently used

the Vref of bank 0, which could cause this pin to be connected to all other bank 0 Vref pins?

-- Gabor

[arnelln]

Here is the Device Status readout:

Maximum TCK operating frequency for this device chain: 25000000.

Validating chain...
Boundary-scan chain validated successfully.
'1': Reading bootsts register contents...
[0] VALID_0 - ERROR OR END OF STARTUP (EOS) DETECTED : 0
[1] FALLBACK_0 - FALLBACK RECONFIGURATION ATTEMPT DETECTED : 0
[2] RESERVED : 0
[3] WTO_ERROR_0 - WATCHDOG TIME OUT ERROR : 0
[4] ID_ERROR_0 - FPGA DEVICE IDCODE ERROR : 0
[5] CRC_ERROR_0 - CYCLIC REDUNDANCY CHECK (CRC) ERROR : 0
[6] VALID_1 - ERROR OR END OF STARTUP (EOS) DETECTED : 0
[7] FALLBACK_1 - FALLBACK RECONFIGURATION ATTEMPT DETECTED : 0
[8] RESERVED : 0
[9] WTO_ERROR_1 - WATCHDOG TIME OUT ERROR : 0
[10] ID_ERROR_1 - FPGA DEVICE IDCODE ERROR : 0
[11] CRC_ERROR_1 - CYCLIC REDUNDANCY CHECK (CRC) ERROR : 0
[12] STRIKE CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS : 0
[13] STRIKE_CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS : 0
[14] STRIKE_CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS : 0
[15] STRIKE_CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS : 0
'1': Reading status register contents...
[0] CRC ERROR : 1
[1] IDCODE ERROR : 0
[2] DCM LOCK STATUS : 0
[3] GTS_CFG_B STATUS : 0
[4] GWE STATUS : 0
[5] GHIGH STATUS : 0
[6] DECRYPTION ERROR : 0
[7] DECRYPTOR ENABLE : 0
[8] HSWAPEN PIN : 1
[9] MODE PIN M[0] : 1
[10] MODE PIN M[1] : 0
[11] RESERVED : 0
[12] INIT_B PIN : 0
[13] DONE PIN : 0
[14] SUSPEND STATUS : 0
[15] FALLBACK STATUS : 0

It looks to me as though it is failing on CRC error.

The reset IC (MAX823) is also a power supply monitor, but the power supply is good, and since the reset line is at ~1V when it should be either 0V or 3.3V I don't think this is the problem.

There are only 2 Vref pins, and both are connected to IO signals.

It just seems strange that I only see this problem when configuration fails on CRC, all other times it works normally, including fails on synchronisation and ID code.

Neill.

[rcingham]

"and since the reset line is at ~1V when it should be either 0V or 3.3V I don't think this is the problem."

Are you sure? The RESET-bar output should normally swing 0.3V to 2.7V unless very heavily loaded.

[arnelln]

I've just noticed I made a mistake in original post, the reset is active low.

I have just lifted the pin on the reset IC and can see that it is driving it high (~3.3V) as expected, but the FPGA seems to be driving the line low.  When I connect the pin back to the pad I then see the ~1V level again.  Which suggests to me that both devices are driving the line in opposite ways.

I have raised a webcase on this as it looks to me as though the FPGA behaves strange when it fails configuration on CRC error.