Issues Downloading Cyclone V Image to EPCS Device / RBF-JIC File Discrepancies

I'm having a difficult time with programming a portion of my EPCQ configuration device and having things behave as I expect on the subsequent power cycle. Any insight into what I'm doing wrong would be appreciated. Device and design questions are off the table (why NIOS vs ARM, why Cyclone V E vs other Altera FPGA, etc.)

my setup and background info:

Cyclone V E FPGA

EPCQ128 Configuration Device

configuration device address map:

EPCQ128 Address 0x000000 Boot Firmware Image

EPCQ128 Address 0x760000 Boot NIOS Image

EPCQ128 Address 0x800000 Application Firmware Image

EPCQ128 Address 0xf60000 Application NIOS Image

notes:

• The board programs via JTAG and a JIC file extremely reliably - no problems.

• I have the Remote Update feature working flawlessly. On power up, the boot firmware and NIOS images load, followed 10 seconds later by the application firmware and NIOS images loading.

• In my NIOS code, I wrote the ability to download new application firmware and application NIOS. The binary data is downloaded to an external SDRAM and CRC verified for correctness before updating the data in the configuration device. It is also read back from the configuration device and CRC verified at the end of the process to ensure the data was written in correctly.

• I have accounted for the bit reversal that needs to happen for the firmware image.

• I can successfully download the application NIOS image multiple times. Each time, the new image runs correctly when the board undergoes a power cycle.

• However, I am having massive difficultly and strange behavior in doing the same with the firmware image. Each time when I download this image, the firmware runs (as evidenced by a Verilog controlled blinking LED) but the nios never boots.

• I ran the examine option from the Quartus programmer and discovered that there are 17 bytes that are different in the beginning 300 bytes of the firmware image - that's it. The remainder of the data is bit-for-bit correct with the original data programmed by Quartus. I'm assuming this is what is keeping my NIOS from booting?

binary file generation:

For the firmware image, I create a RBF from the source SOF. I handle the bit reversal, download, and program this data.

For the JIC file, I create it from Quartus using both SOFs (addressed on different SOF pages) and both NIOS memories (each showing up at their appropriate address).

file comparison:

When I compare the application RBF data to the application data embedded in the JIC file, these 17 bytes are already different. See attached JPG for the comparison (JIC on left, RBF on right). My question is what is going on? Why is this difference already present? How do those bits prevent the NIOS from booting?

Am I doing something basic that is wrong? Are there other preferred ways of generating the data that I need to send? If I replace those 17 bytes with the original 17 bytes manually, will it work?

Any insight is greatly appreciated. I'm basically out of ideas at this point. If the tool is giving me a file that's wrong, that's a problem.