Programming a complete bit file is OK.
Programming the following small example file is not OK:
:020000040008F2
:102F8000000102030405060708090A0B0C0D0E0FC9
:102F9000101112131415161718191A1B1C1D1E1FB9
:00000001FF
Verify is OK, but here is the data from a readback of the whole device after programming the file above
(only the interesting lines are shown):
:020000040008F2
<******* lines deleted here ***********>
:102F6800FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF69
:082F7800FFFFFFFFFFFFFFFF59
:102F8000101112131415161718191A1B1C1D1E1FC9
:102F9000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF41
The first 16 bytes of the programming file have disappeared and the following data is off by 16 bytes.
To get data where I want, I must add dummy data at the beginning of my mcs-file and adjust addresses by 16 bytes.
If I append my small file to a complete bit-file that begins at address 0, the problem is not there. In that case my data loads to the correct addresses.
The following is not related to the problem, but is included to show that I understand the strange memory layout and the "default addressing mode" of the xc3s200an:
The wanted starting address for the data is 0x82f80 in the mcs-file which corresponds to address 0xfe000 in xc3s200an in the "default addressing mode" (264-byte pages with 512-byte spacing). This address is at the beginning of a page (the smallest erasable unit). The addressing in the mcs-file is linear with no gaps.
Some lines in the readback are shorter, and the reason is that a page always starts at the beginning of a line. A 264 byte page means 16 lines with 16 bytes each and one line with 8 bytes. This means that the readback confirms that address 0x82f80 is at the beginning of a page, which really doesn't matter for this problem.
