Felix Posted March 27, 2013 Report Share Posted March 27, 2013 using the commandline :papilio-prog.exe -v -f final.bit -b bscanBLAH500.bit -sa -r programming something as simple as invaders takes forever. (183426.7ms <-- ~3 mins) is that the right way to program it to flash?how do you get the fpga to reboot or whatever afterwards? i would have thought that -r would do it, but if it does, its taking forever.unplugging the p500 from the usb and plugging it back in starts thebitstream that was programmed to the flash. (papilio-prog.exe -j will work to reset/reboot/whatever the fpga instead of unplugging it/plugging it back in)[edit::: seems that papilio-prog.exe -c will also do that according to the arcade blaster source, assuming i read it right] i dont remember the arcade blaster app taking that long to program to flash...i could be mistaken tho. i wonder if its something with windows 8 Link to comment Share on other sites More sharing options...
alex Posted March 27, 2013 Report Share Posted March 27, 2013 papilio-prog.exe -j alone does not reset the FPGA. The only way I've found to script an FPGA reload is withpapilio-prog.exe -rwhich will trigger the reconfiguration but cause the FPGA to remain stuck, then eitherpapilio-prog.exe -corpapilio-prog.exe -jto release the FPGA so it runs again. EDIT: I had a look Jack, in file progalgxc3s.cpp it seems if you duplicate the BYPASS command as below, the -r option will trigger a reconfiguration then release the FPGA again so it runs, perhaps you can test and patch the code on github if you're happy with this.void ProgAlgXC3S::Reconfigure(){ jtag->shiftIR(&JPROGRAM); jtag->shiftIR(&BYPASS); jtag->shiftIR(&BYPASS);} Link to comment Share on other sites More sharing options...
Felix Posted March 27, 2013 Author Report Share Posted March 27, 2013 thanks for the reply i may just check out the source and fork it if its in github.[edit: seems it is https://github.com/GadgetFactory/Papilio-Loader/tree/master/papilio-proglooking at the source, it seems that the -r switch sends the same command to the fpga as -cbut it sends it right after another command. i will see about recompiling it with a second or so delaybetween commands and see if that fixes -r.if that made sense. i have been up all night @ work.] [edit 2::Forked and made the change. now to either compile or let someone else compile and test for me..] Link to comment Share on other sites More sharing options...
alex Posted March 27, 2013 Report Share Posted March 27, 2013 I did try a jtag->Usleep(10000); delay between JPROGRAM and BYPASS but it didn't make a difference. Link to comment Share on other sites More sharing options...
Felix Posted March 27, 2013 Author Report Share Posted March 27, 2013 strange. will dig into it when i havent been awake @ work all night. why 10000 and not 1000 ? [edit:just saw your edit... thanks ] Link to comment Share on other sites More sharing options...
alex Posted March 27, 2013 Report Share Posted March 27, 2013 Because it's... uhmmm... longer Why, is it out of range? Link to comment Share on other sites More sharing options...
Felix Posted March 27, 2013 Author Report Share Posted March 27, 2013 no clue just seems a bit long. i cant get this to compile on my current VC++ setup nor my centos box (no mingw32) will try again later after i have had some sleep. goin on 18.5 hours awake now.. Link to comment Share on other sites More sharing options...
mkarlsson Posted March 27, 2013 Report Share Posted March 27, 2013 papilio-prog.exe -j alone does not reset the FPGA. The only way I've found to script an FPGA reload is withpapilio-prog.exe -rwhich will trigger the reconfiguration but cause the FPGA to remain stuck, then eitherpapilio-prog.exe -corpapilio-prog.exe -jto release the FPGA so it runs again. EDIT: I had a look Jack, in file progalgxc3s.cpp it seems if you duplicate the BYPASS command as below, the -r option will trigger a reconfiguration then release the FPGA again so it runs, perhaps you can test and patch the code on github if you're happy with this.void ProgAlgXC3S::Reconfigure(){ jtag->shiftIR(&JPROGRAM); jtag->shiftIR(&BYPASS); jtag->shiftIR(&BYPASS);}Yeah, the reconfigure code in papilio-prog is basically a NOP. It's been corrected in the Pipistello version of papilio-prog. You can see the code here:http://www.saanlima.com/download/fpgaprog-win.zip The updated code to make reconfigure work is in the Reconfigure function in file progalgxc3s.cpp Magnus Link to comment Share on other sites More sharing options...
Felix Posted March 27, 2013 Author Report Share Posted March 27, 2013 thanks mkarlsson. will see if we can get jack to commit/release also. Link to comment Share on other sites More sharing options...
Jack Gassett Posted March 27, 2013 Report Share Posted March 27, 2013 Ok, this will be good to get sorted out, I'll put it on the list. Jack. Link to comment Share on other sites More sharing options...
mkarlsson Posted March 27, 2013 Report Share Posted March 27, 2013 I haven't tried Alex suggestion, I basically just copied the reconfigure code from xc3sprog and it works, at least for me. Link to comment Share on other sites More sharing options...
alex Posted March 27, 2013 Report Share Posted March 27, 2013 Good work Magnus, I took a look at your code and I have a question (I can't test it because I'm at work currently). While the comments in your code agree with xtp038.pdf the actual command you're sending to the FPGA differs. In the commands you're sending, the sync word doesn't match, and the commands don't look right. byte xc6sbuf[12]= {0xff, 0xff, 0x55, 0x99, 0xaa, 0x66, 0x0c, 0x85, 0x00, 0x70, 0x04, 0x00};Whereas the comments indicate you should be sending: byte xc6sbuf[12]= {0xff, 0xff, 0x99, 0xaa, 0x66, 0x55, 0xa1, 0x30, 0x0e, 0x00, 0x00, 0x20};EDIT: Oops I missed your post where you mentioned you copied this from xc3sprog, I guess then you might not be able to answer the question. I have a feeling that simply shifting a certain command into IR then moving junk into the DR causes the FPGA to reset due to the DR data sync word mismatch. Hence why it appears to work even when sending BYPASS twice (0x3F, 0x3F). More guessing, but it looks like the FPGA needs at least a word (two bytes) shifted into DR at a time, hence why it hung there when sending just one BYPASS command, it expected one more byte. After receiving two bypass commands it realises that 0x3f3f is not a valid sync word and exits and resets. Link to comment Share on other sites More sharing options...
mkarlsson Posted March 27, 2013 Report Share Posted March 27, 2013 I didn't notice the difference between the comments and the actual sequence of bytes, I just did a copy-and-paste, recompiled, and it did reconfgure the parts after the flash programming so I was happy. Maybe this is some kind of alternate way of doing it, the sequence is the same as for xc3 but it has two sync words instead of one like xtp038.pdf but the nybbles in the sync words are scrambled. Link to comment Share on other sites More sharing options...
alex Posted March 27, 2013 Report Share Posted March 27, 2013 I'll muck around with this during Easter for my own curiosity, I'll need to research what JTAG commands and data the FPGA understands. EDIT: UG380 page 130 & 159 looks like a good start. EDIT 2: Oh grrr, all the fields are byte swapped and bit reversed, now it all makes sense. Each 16 bit configuration data packet that is not a dummy or a sync word consists of a certain bit field.Packet format, pages 92, 93:TYPE - OP - REGISTER - WORDCOUNT15 14 13 - 12 11 - 10 9 8 7 6 5 - 4 3 2 1 0Where TYPE can be binary 001 or 010 (type 1 or type 2), page 93OP only 3 defined, binary 00 NOP, 01 READ, 10 WRITE, as per page 92REGISTER defined on page 94, 95, too many to list here. Valid range 0x00 - 0x22 (6 bits)WORDCOUNT is the number of data words expected to follow this wordHere's my interpretation of the data according to the info in UG380.byte xc3sbuf[12]= { 0xff, 0xff, byte swapped & bit reversed is FFFF dummy word 0x55, 0x99, byte swapped & bit reversed is AA99 sync word 0x0c, 0x85, byte swapped & bit reversed is 30A1 = 001 10 000101 00001 = type 1, WRITE, CMD register, 1 word follows (see below) 0x00, 0x70, byte swapped & bit reversed is 000E = IPROG command 0x04, 0x00, byte swapped & bit reversed is 0020 = 001 00 000000 00000 = type 1, NOP command, n/a, n/a 0x04, 0x00 byte swapped & bit reversed is 0020 = 001 00 000000 00000 = type 1, NOP command, n/a, n/a};byte xc6sbuf[12]= { 0xff, 0xff, byte swapped & bit reversed is FFFF dummy word 0x55, 0x99, byte swapped & bit reversed is AA99 sync word 0xaa, 0x66, byte swapped & bit reversed is 5566 sync word 0x0c, 0x85, byte swapped & bit reversed is 30A1 = 001 10 000101 00001 = type 1, WRITE, CMD register, 1 word follows (see below) 0x00, 0x70, byte swapped & bit reversed is 000E = IPROG command 0x04, 0x00 byte swapped & bit reversed is 2000 = 001 00 000000 00000 = type 1, NOP command, n/a, n/a}; Link to comment Share on other sites More sharing options...
mkarlsson Posted March 29, 2013 Report Share Posted March 29, 2013 Wow. Byte swapped and bit-reversed. Good job tracking that down! Link to comment Share on other sites More sharing options...
cjameshuff Posted April 9, 2013 Report Share Posted April 9, 2013 using the commandline : papilio-prog.exe -v -f final.bit -b bscanBLAH500.bit -sa -r programming something as simple as invaders takes forever. (183426.7ms <-- ~3 mins) ... i dont remember the arcade blaster app taking that long to program to flash... i could be mistaken tho. i wonder if its something with windows 8 On my Linux Mint machine, it takes 21 s to write and verify a 278 kB bit file, so there may be something strange there. There's two FTDI libraries, and IIRC papilio-prog can be compiled with either one. Try recompiling it with the other one? Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.