When I upload an HEX or a MIF using the USB BLASTER and the in direct memory editor in batch more (using
quartus_stp -t input.txt where input.txt contains
begin_memory_edit -hardware_name "USB-Blaster \[USB-0\]" -device_name "@1: EP3SL340 (0x021050DD)"
update_content_to_memory_from_file -instance_index 0 -mem_file_path "../image/prom1.hex" -mem_file_type "hex"
update_content_to_memory_from_file -instance_index 1 -mem_file_path "../image/prom0.hex" -mem_file_type "hex"
This can fail on a new sof because Quartus changes the ID order on each remapping (I have no control over it).
We use 25 RAM/ROM.
The help does not mention anything aside -instance_index:
Usage: update_content_to_memory_from_file [-h | -help] [-long_help] -instance_index <instance index> -mem_file_path <path> -mem_file_type <file type>
-h | -help: Short help
-long_help: Long help with examples and possible return values
-instance_index <instance index>: Index of the editable memory instance to modify
-mem_file_path <path>: Path to the memory file to load the memory content
-mem_file_type <file type>: Type of the memory file such as "mif" or "hex"
If we could target an ID name, then it will be compatible over different sof files as we do not change the ID name of the ROM/RAM.
You will need to use the "In-System Memory Content Editor" GUI which is part of the Quartus software to determine the Index number for each instant ID. The reason is that the cmd line method is a simplified method to performed which only accept Index number.
You may refer to https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/qts/qts_qii53012.pdf for more information on how to use the editor.