hamster 47 Report post Posted March 6, 2011 Hi Jack (and others). I've just been bashing my head against a problem - if I convert the AVR 'hex' file and put it in the VDHL for program memory it works, but when I merged the same hex file in with data2mem it didn't. I traced it down to srec_cat + data2mem giving different results depending on the length of the line in the lines in the '.mem' file generated by srec_cat. If the lines in the '.mem' file had 0xFF bytes it the second line merges in the wrong place (maybe due to byte swapping???). By using "srec_cat program.hex -Intel --byte-swap 2 -Data_Only -Line_Length 105 -o program.mem -vmem 8" the lines came out a convenient 32 bytes of date per line, and it merged in correctly. This was using srec_cat version 1.47.D001. Hope this helps somebody avoid the struggles I had. Cheers Mike. PS. Thanks for your efforts in porting the AVR8 to Xilinx - I am currently running this core on a Digilent Nexys2 - now that I have it up and running an order for a Papilio one will go in as soon as disposable income will allow! Share this post Link to post Share on other sites
Jack Gassett 0 Report post Posted March 7, 2011 Hello Mike, Thank you for posting about this, it is something that I struggled with mightily when I was getting the AVR8 up and running. Everything worked fine in simulation and short programs worked just fine. But programs that grew beyond a certain size would show unpredictable behavior! It seems to be a bug with data2mem, it won't handle the output from srec_cat if it wraps to a second line. It's completely fine if everything stays on one line but as soon as it starts a new line it messes up a couple of bytes in memory. It was a huge hassle to track down. I also tried to use command line options for srec_cat to try and force all data onto one line but never found a solution that worked right with a large application. I ended up using gawk to force a format that data2mem does not choke on: gawk ' BEGIN{FS=" ";} { $$1= ""; print}' tmp.mem > out.mem I'll have to test out your solution, it would be nice to remove the gawk step. Jack. Share this post Link to post Share on other sites
hamster 47 Report post Posted March 10, 2011 Phew! Glad it's not just me. I eventually worked it out by running "data2mem -bm x.mem -bt x.bit -d" to dump the bitstreams and then running "diff" on the two outputs. It would be worth putting in a bug report to XIlinx, but that would most probably need me to be a registered user. Share this post Link to post Share on other sites
Guest pepevi Report post Posted March 21, 2011 Hope this helps somebody avoid the struggles I had. Thanks Mike, I'll check out your optimization. Share this post Link to post Share on other sites
ssh105 0 Report post Posted August 11, 2015 Hi, Do any of you guys know how I can recreate the problem? I didn't quite get how to get the AVR 'hex' file and how to put it in the VHDL for program memory or to merge it with data2mem Share this post Link to post Share on other sites
ssh105 0 Report post Posted August 11, 2015 i assume you guys are merging the Bootloader HEX-file and Application HEX-file Share this post Link to post Share on other sites
Jack Gassett 0 Report post Posted August 11, 2015 Take a look at this makefile to see all of the steps for the process:https://github.com/GadgetFactory/DesignLab/blob/ZAP-V2.0.3/hardware/tools/papilio/Makefile Share this post Link to post Share on other sites
