Image size is ambiguous

[Altera_Forum]

Hello, 

 As I already posted in the JTAG verification thread, we are using an ARM9 CPU to program our Cyclone 2 EP2C8 FPGA chip. I wrote the device driver to do this via the PS configuration scheme. My Hardware collegue supplied me a hex file, which I converted to binary format using a custom own built tool, that has been proven to work in the past. The tool generates a file of exactly 247944 bytes. My driver states an error concerning that the CONFIG DONE line is up while still having to send the last two bytes. This is odd. I took a hex editor and cut off the last two bytes, making the loading of this file a success. Also the INIT_DONE line goes up, and I can see an oscillating signal on one of the test pins (which is good). The Altera specification states that an image should be 247974 bytes, which is 32 bytes more than is accepted.... I also tested in making the image even 6 bytes smaller than the one that is currently working, and here also the FPGA thinks it's OK (CONFIG_DONE and INIT_DONE lines are both high.  I am to say the least confused..... Can anyone clarify which image size is correct ?  Thanks, Bart

[Altera_Forum]

If no one provides an answer here, please file a service request. It might be that the number you found in the documentation is wrong and needs to fixed. 

 I think I've seen numbers for configuration size have a qualifier in the documentation saying that the numbers are approximate. When I've been asked the actual size, I think I've generated a programming file in a format that makes it easy to see the actual number of bytes (instead of relying on the numbers in the documentation). It's been a while since I've done that, but I think I might have used the raw binary file (.rbf) size under the assumption that there are no overhead bytes in that file.  I don't remember hex files including any overhead bytes, but I'm pretty sure tabular text files do not. You could compare a .ttf file to your hex file to see whether the .ttf file omits the apparently extra bytes that are in the hex file.