Issues with srec_cat.


Recommended Posts

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.



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!

Link to comment
Share on other sites

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.


Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 2 weeks later...
  • 4 years later...


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