Hi,I am trying to generate an EPCS64 pof file with sof and two hex files. One hex is my nios code (relative addressing). The second hex (absolute addressing with 0x7F0000 offset) is a tiny 64 char text string that I want to appear at the start of the last block of the epcs when programmed (this is an indicator that I can use for application specific flash status read). If I generate the pof from just the sof and nios hex the generated file is exactly 8192 k bytes as expected. The individual sof and hex are only half the size of epcs64 so I guess the extra bytes generated are padding?. However then if I add the tiny indicator hex (generated with 0x7F0000 offset) I get a device full "exceeds memory capacity" error from "Convert Programming File" Utility, Anyone know how I can add this second hex file to the pof without exceeding the memory? Or perhaps another method to insert the indicator string at specified epcs address? Thanks,
Are you getting a .map file generated after executing the conversion utility? If so, it will list the address and size of the sections, possibly giving you a clue what is happening. If you're already using >7F0000 with the .sof+nios.hex, you won't be able to put your indicator.hex there and I think that is what it is complaining about.
Thanks. Looking at the map file I can see that when I add the second hex file its placing the nios code after it and thats the reason for memory exceed.So it seems using the Convert Programming File utility will place a "Relative addressing" hex at location after other hex files (not just after the sof). Hex Data Nios -- Relative addressing -- <auto> Hex Data Tiny -- Absolute addressing -- 0x007F0000 Sof Data -- Page_0 -- 0x00000000 This results in the Nios code being placed after 0x7F0000... I cant seem to change the priority in Convert Programming Files... So the question now becomes: How do I include two hex files and keep the nios code as relative addressing directly after sof and then add another hex file with absolute addressing after that?
I don't recall running into the problem you are, but for what it's worth, I'm using absolute addressing for all my .hex files (doing basically the same thing as you) and maybe that's why.
--- Quote Start --- I don't recall running into the problem you are, but for what it's worth, I'm using absolute addressing for all my .hex files (doing basically the same thing as you) and maybe that's why. --- Quote End --- .. ok thanks... so if you use absolute for your nios code are you manually entering the address to be directly after the sof? Or do you have a custom bootloader that jumps to know address? Both these I was hoping to avoid....
--- Quote Start --- .. ok thanks... so if you use absolute for your nios code are you manually entering the address to be directly after the sof? Or do you have a custom bootloader that jumps to know address? Both these I was hoping to avoid.... --- Quote End --- I'm using the chain of commands (sof2flash, elf2flash, objcopy) from this article: http://www.altera.com/support/kdb/solutions/rd10132010_126.html i.e. use those commands to dynamically figure out where to put your NIOS code
Thanks for your comments.Sorted the issue, the sof file needed compression enabled to ensure that the sof end address matches with the elf2flash --after address. Now I can add multiple hex and use Relative addressing start address - 0x0 for each.