Papilio Plus Issue


Guest monkeydoo

Recommended Posts

Guest monkeydoo

I am having issues uploading a bitstream to the prototype board I purchased.  Since I seem to be the only person having problems I assume it's something wrong my end.

I am using the Papilio Loader 1.7 marked as latest in GitHub.

Uploading via JTAG, sometimes it works.  Sometimes it doesn't.  I cannot offer any more than that.  I have tried an other computer to try to illiminate software/USB port issues.  I believe my board still has the "quickstart" bitstream from the test package on the external flash.  Basically I can quickly tell when the bitstream loads because LED1 goes out.

Also, I am completely unable to flash the external flash.  I receive the following message.  Possibly the "SPI flasher" bitstream isn't loading?

 
Programming to SPI Flash
Using devlist.txt
Programming a Papilio Plus LX9
Using devlist.txt
JTAG chainpos: 0 Device IDCODE = 0x24001093    Desc: XC6SLX9
Uploading "bscan_spi_lx9.bit". Done.
Programming time 575.0 ms
Programming External Flash Memory with "C:\Users\user\Desktop\FPGAST~1\PAPILI~1\
LX9COD~1\READAD~1\main.bit".
Uknown Flash Manufacturer
Error: SPI Status Register [0x00] mismatch (Wrong device or device not ready)..
Error occured.
USB transactions: Write 171 read 4 retries 0
Using devlist.txt
JTAG chainpos: 0 Device IDCODE = 0x24001093    Desc: XC6SLX9
ISC_Done      = 0
ISC_Enabled    = 0
House Cleaning = 1
DONE          = 0
Press any key to continue . . .

Any ideas where to start?

Link to comment
Share on other sites

Hey monkeydoo,

 

  So with the Papilio Plus we are using a much larger, 64Mb SPI Flash that  is not supported by the papilio loader yet. I spent a couple days  struggling with it and wasn't able to get the chip to go into write  mode. Luckily Alvaro helped me out and we were able to program the SPI  Flash chip using the ZPUino a couple days ago. Now that there is a  working model to look at I should be able to add support the the papilio  loader, maybe early next week.

 

  If you really need to program the SPI flash before that I've attached an  archive with everything needed to do so with the ZPUino. Be sure to  load the papilio_plus_lx9_v1.2.bit file to the papilio before running  the bat file.

 

  As far as not programming a bit file every time, we need to get to the  bottom of what is happening. None of the boards went out with any kind  of bit file loaded to SPI Flash. (The test file was written for the  older Papilio Plus that used a supported 4Mb SPI Flash) So the SPI Flash  should be completely blank...

 

  LED1 going off after the bit file loads is dependent on the bit file  that is being loaded and is not a good indication of success. I've  noticed that with a good bit file it usually does go out, but if I load a  LX4 bit file instead of a valid LX9 bit file it will stay on. So I  would ask if you could use the papilio_plus_lx9_v1.2.bit file in the  attached archive and load it to the board several times. This bit file  is known to turn LED1 off when loaded successfully so load it several  times and let me know how it looks.

 

  Thank you for your patience, we will get to the bottom of this and make sure you end up with a good working board.

 

  Jack.

 

 

program_spi_with_zpuino.zip

Link to comment
Share on other sites

Guest monkeydoo

Thanks.  I am happy to work through this.

Ok..  I wasn't aware programming the SPI flash wasn't quite ready yet.  No worries, I must have missed that.  I have no immediate need to do so.

During my test I was using the bitstreams for the LX9 from the test plan package.  I was using the one that does the I/O tests (requiring the stimulus board).  Obviously it was failing the tests without it but the serial output was enough to show it had loaded the bitstream.

I will play some more and see what I can come up with. 

BTW, I am extremely impressed with these devices so far.  It looks like I can literally fit my existing code 3-4 times over in the S6 LX9. This is actually useful in my case because I can implement multiple receivers simultaneously.

Cheers,

Ian

Link to comment
Share on other sites

Guest monkeydoo

The bitstream from the archive loaded once using Loader v1.7 in over 15 attempts :)

I could never get it to load with the 2.0 Beta.  I was occasionally pulling the USB cable between attempts.  The one time it did load wasn't immediately after the power being removed.

I read "jheckman" noticed the INIT_B was being used as I/O.  If you think this could be related, I could tie that pin high?

Link to comment
Share on other sites

You could give that a try, I've done a lot of research and testing of the INIT_B issue so far and its something I'm concerned about but I don't think that is what's happening here...

I would probably like to swap boards with you though so I can study the problem with your board in more detail. I'm going to halt the production run of Papilio Plus boards until I feel comfortable that INIT_B is not a problem.

What I've seen with the boards I have on hand is that the SRAM holds INIT_B at 3.3V at power on and there is no hiccup with the board.

Jack.

Link to comment
Share on other sites

Guest monkeydoo

Jack,

Sorry for the delay.

I tried pulling INIT_B high with no change.

I'm sorry to say this looks like a software issue.  Eventually I tried inserting the Papilio into a Windows XP VM running on the same laptop as I always use.  It programs in XP first time, every time.

I do have another physical computer which has the same problem programming these boards and OK with the original Papilio.  The only piece of information I can offer is they both run Windows 7-64bit.  The VM running XP is 32bit.  Perhaps a driver issue.  I have no idea really.

Ian

Link to comment
Share on other sites

Ian, things have got a little crazy so I haven't been able to put as much time into figuring this out as I'd like to. But I did spend a full day digging into this and here is what I saw.

I'm seeing issues with every single Papilio Plus board I have not programming correctly 100% of the time. If I program the same bit file repeatedly it will fail every 4th or 5th attempt. Then the next one works fine. I was afraid it might be INIT_B related so I halted the production run until there is a solution. I did a lot of testing by removing the SRAM chip and trying combinations of holding INIT_B high and low and floating. I also programmed a bit file to SPI Flash and hit reset over and over again while trying to manipulate INIT_B. The bit file loads from SPI flash every single time perfectly. So I feel 99% that we are not looking at a problem with INIT_B. I have come to the same conclusion that the issue is with the Papilio Loader application. I suspect that these early generation Spartan 6 chips just need the programmer to be slowed down a little bit. Right now it takes 600mS to program a bit file. I think that if I slow things down so it takes more like 1 second to program the bit file we will probably see 100% success.

It also fits that you are seeing more problems under Linux then Windows. The timing code is different depending on whether Linux or Windows is the target OS.

Jack.

Link to comment
Share on other sites

Guest monkeydoo

OK.  Glad you are making progress.

I also thought it may be delay related.  I was never able to get the board to program with Papilio Loader 2.0, only 1.7.  I wonder if there is a subtle difference between versions.

The laptop I use is pretty fast (i7 yadda yadda) .  I was thinking about the overheads in the pass through USB device to the VM may cause the needed delay.

It also won't program over JTAG with my hardware plugged in with it's data clock running... ever.  The original Papilio had no such issue.

Ian

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.