search

douggilliland / R32V2020

My 32-bit RISC CPU for smallish FPGAs
GNU General Public License v3.0
17 stars 3 forks source link

Touch up hex file #31

Closed mjgpy3 closed 5 years ago

mjgpy3 commented 5 years ago

See https://github.com/douggilliland/R32V2020/issues/28#issuecomment-493681182 for more info.

douggilliland commented 5 years ago

Very nice. One more detail (there's always one more detail). There's one last record at the end of the .HEX file. Here's one from the files I made. :00000001FF

douggilliland commented 5 years ago

Looks like this value is a hard coded value. I think it flags the HEX loader that it's the end of the hex data. I will manually patch it in for now. Described on page 11 of the document:

douggilliland commented 5 years ago

So glad you wrote the assembler code in my reduced Python mentality. I was able to easily find the line and write out the end of file record!

mjgpy3 commented 5 years ago

@douggilliland nice!

douggilliland commented 5 years ago

@mjgpy3 Something strange about it. The program may be wonky that uses it. Digging into the reason but it looks great to me.

douggilliland commented 5 years ago

@mjgpy3 The hex file address field is shifted right by two digits: This is what the assembler puts out: :04000000208000005C :040000012088100043 :040000022071000069

This is what it should be: :04000000208000005C :040001002088100043 :040002002071000069

https://web.archive.org/web/20160607224738/http://microsym.com/editor/assets/intelhex.pdf

douggilliland commented 5 years ago

Fixed assembler.

Now matches the dump file.

Once again, easy to find/fix.

douggilliland commented 5 years ago

Finally got it all to really work. Final issue was Quartus did not do the path right to the HEX code. Ended up moving it into a place relative to the VHDL code so that Quartus got and loaded the HEX file. Worked great.