Spartan® Family FPGAs

[jonpry]

  I have a custom board with an XC6SLX45 in FG484 in theory configured for master SPI mode.

VCCAUX is 3.3V, VCCO_0 and VCCO_2 are 2.5V, VCCO_1 is 1.8V and VCCO_3 is 3.3V. All the supplies appear to ramp monotonically. M0 = 2.5V, M1 = GND, HSWAP = 2.5V

After powerup, or after pulsing prog_b low. I see init_b go high and then about 200ms later go low again. There is no activity on any of the lines to the flash memory (which all have pullups and the clock is properly terminated).

Any ideas? I find it interested that init_b appears to time out. This suggests that the chip is in some kind of master mode. Just there is no activity on the i/o.

[eteam00]

There is a broad range of possible problems, and you have provided few details and information bits.

• If you have experience configuring the part through the JTAG port (e.g. iMPACT), this would be useful information.

• Are you able to program SPI flash memory?  With iMPACT (indirect programming)?

• Would you mind posting your board schematics?

• Have you tried GNDing HSWAPEN?  Is this board used in a hot-swap application?

• Do you have more than one copy of this board?  If yes, do they all exhibit the same behaviour?

• Has this board's behaviour changed (e.g. more reliable, less reliable, different anything...)?

• What other troubleshooting have you already done?

• Is the self-configuration failure absolutely consistent?  Are there any variations in behaviour that you have noticed?

-- Bob Elkind

[jonpry]

Bob,

If you have experience configuring the part through the JTAG port (e.g. iMPACT), this would be useful information.

     There is no access to the jtag port of the chip on this board. So I have not been able to verify anything via that method.

Would you mind posting your board schematics?

   I have attached the schematics for the fpga portion of the board. Decoupling capacitors are on a different page but are populated according to the datasheet guidelines.

Have you tried GNDing HSWAPEN?  Is this board used in a hot-swap application?

   There is no way to change HSWAPEN on this board. I have a natural aversion to pullups on everything. I have discrete pullups for everything that requires one including the spi flash.

Do you have more than one copy of this board?  If yes, do they all exhibit the same behaviour?

   There is currently only one board. I have some more bare boards and building them up is definitely one of my next moves.

Has this board's behaviour changed (e.g. more reliable, less reliable, different anything...)?

    Not really. I have described the behavior as best I understand it. Nothing has changed.

What other troubleshooting have you already done?

    I have tried to measure all supplies on my storage scope and watch this sequence of events as it unfolds. Gone over the schematic and datasheets  50 times. Pushed prodded and poked all things looking for changing behavior.

[eteam00 · Accepted solution]

There is no access to the jtag port of the chip on this board. So I have not been able to verify anything via that method.

There is no way to change HSWAPEN on this board. I have a natural aversion to pullups on everything. I have discrete pullups for everything that requires one including the spi flash.

These are choices you make for a production board, where the design has already been proven and debugged.  Debugging tools such as probe points, JTAG ports, and discrete resistors are not frills, they are inexpensive aids which save time and money.  Extra connectors and resistors are easy to remove or de-populate for production runs.  You get the idea, right?

You have left the SUSPEND pin floating.  This is most likely a source of your problems.  If you look through the Spartan-6 Configuration User Guide UG380, the SUSPEND pin is explicitly mentioned roughly 3,408 times in the document.  And the advice is:  the SUSPEND pin should be LOW during configuration.

Actually, this advice is wrong.  It should read:  the SUSPEND pin MUST be LOW during configuration.

The SUSPEND pin is one case where you have my full blessing to tie the pin directly to GND.  But only after you have confirmed the board layout footprint that the pin tied to GND is indeed the (correct) SUSPEND pin.

See this thread.

Good luck.

-- Bob Elkind

[jonpry]

 Bob,

    I had previously seen that thread regarding the suspend pin and determined that unlikelly to be the problem because configuration does not really seem to start. This morning I popped the chip off, soldered a small jumper from suspend to ground and put a new chip on. Now it configures. So I guess I have created yet another inconclusive test with regards to the suspend pin. Could have been a bad chip, bad soldering, or the suspend pin.

Thanks for your help.

~Jon

[eteam00]

So I guess I have created yet another inconclusive test with regards to the suspend pin. Could have been a bad chip, bad soldering, or the suspend pin.

If you have doubts about the need to tie SUSPEND pin to GND, disconnecting the newly-added SUSPEND pin jumper should clear away any such doubts.

Xilinx has made it explicitly clear, even if you (perhaps) also had a 'bad chip', the floating SUSPEND pin would have undoubtedly stopped you in your tracks until corrected.  The SUSPEND pin fix is absolutely necessary, and this is the message which other, less experienced readers/designer must gather from this thread with absolute clarity.

If this board design will be going forward with revisions, my suggestions for board revisions have already been made in this thread.

When you get the chance, please mark this thread as 'solved'.  Good luck to you with the rest of your design!

-- Bob Elkind