Debugging Spartan3 slave serial configuration

"Yaju Nagaonkar" schrieb im Newsbeitrag news: snipped-for-privacy@o13g2000cwo.googlegroups.com...

1) you can use impact to query the configuraton status after your config attempt, as example you can see if there was CRC error, etc. but my bet it only say init ok, done = 0 2) make sure you have startupclock set CCLK

3) if in doubt reverse bit order in bytes

4) send some more dummy bits after end

I am using mega8 to load Spartan3 and virtex4 over JTAG from SD-Card and I have no problems. slave serial is even simpler to implement, just send the .BIT file into DIN and that should do it

note that INIT will not flag error if the proper signature is never seen

Antti

Antii,

Thanks for you reply.

I tried all your suggested options. I am having even more bizzarre issues. I modified my process as

Verified that the startup clock is set to CCLK (as a part of Implementation option of the XST synthesis tool).

1. assert FPGA PROG# pin low.
2. De-assert PROG# high.
3. wait for INIT# to go high.
4. Unpack the byte (into bits) from configuration file (BIN file) and place first bit (LSB) of bitstream on DIN.
5. pulse CCLK high then low.
6. repeat 4, 5 for remaining bits of bitstream. While doing this monitor the INIT# line. If it goes low, the FPGA has detected a bitstream error.
7. place 1 on DIN.
8. pulse CCLK high then low. (for like 10 dummy clock cycles).

The DONE goes high after like 30 seconds (after configuration has ended) or something, but my actual code (LED blinking) never happens.

And then after another 30seconds later the DONE goes low!!!!!

So I connected the JTAG pins and used IMPACT to read the status register. These pins were different from succesful JTAG configuration. status of GTS_CFG_B : 0 status of GWE : 0 status of GHIGH : 0

And the INIT_B was high and DONE was low.

Any ideas!!!!!!!!

-Yaju

Never mind. I fixed it.

I was sending the bits LSB first. That is incorrect.

The spartan-3 requires the bits MSB first. I also had a few problems with my data transfer, since I have not implemented any sort of flow control. My system basically implements the crudest of flow control, i.e. write and read back the byte. This is insanely slow and I will be implementing other faster flow contol mechanism, now that my serial configuration system works.

Thanks Antti.

Yaju Nagaonkar

--
Electrical and Computer Engineering
Brigham Young University
Provo UT 84602
yaju [(shift+2)] byu edu

"Yaju Nagaonkar" schrieb im Newsbeitrag news: snipped-for-privacy@g49g2000cwa.googlegroups.com...

:)

you did not follow my instructions full, number [3] of the advices was to use different bit order in bytes 'just in case'

its a generic trouble solver if one setting that can influence the result can have two values, then check out both - even if you thing your current setting is correct.

Antti

I actually did follow your instructions. I was having problems with the flow control which I had to fix before I could get back to your instructions. Thanks eitherways.