Think I’ve got a pretty good idea.
The DFU volume info is recognized properly…
First of all, I don’t think these DFU “volumes” really exist. These are just fabricated information
meant to make Windows (or whatever compatible OS being accessed) believe they are a
valid FAT12 directory and make the host OS send the file over to it. Once the DFU code
receives this, it operates as a ROM programmer, and loads the streamed data into proper
place on the ROM. So they can be written to represent any size at all.
The ability to parse out HEX files shows why they are the size they are, and why 2MB is needed.
In the early devices, only 256KB was officially recognized, leaving 128KB for programs. When
loading a HEX file, approx 3X the room is needed (each byte is a 2 byte hex character, +
overhead for the addresses). So 512 was chosen to cover 128 x 3.
With the advent of 512KB ROM in HW2.81, this needed to be expanded to approx 350KB x 3
which is a bit over 1MB, so 2MB had to be chosen.
Also instituted with the later devices, appears to be some safeguards to prevent code from
overwriting important info. In such a case, it appears that the ROM loading stops, the volume
unmounts (such as with the generation of a RDY “file”) and some error sounding file name
is then created in a remounted volume. Apparently, different versions of Windows may react
to this differently, as a volume dissapearing while in write mode, before the write is finished
could certainly “confuse” things.
In any event, the DFU drives are working as they are intended, with different versions of Windows
loading errors in possibly somewhat different ways. What we need to know now, is just what
constitutes areas of the ROM we need to keep away from. Before these latest “safeguarding”
DFU versions, programmers relied on known information as to where the bootloader, system,
program area(s) and the various apps from different programmers, FPGA and LOGO reside,
as well as some common sense areas such as the first 16KB past 256K where, on a true 256KB
device, ROM loads could “roll over” and possibly come back and wipe out the DFU, and stay
away from these, not to forget that on later devices, these appear at different places, so for
true compatibility, BOTH areas have to be avoided.
More info from the manufacturer would certainly be warranted, after all if these devices are MEANT
to have programs written for them, we need to know where to put the code…
In the mean time, all we can do is trial and error. So far with the help of wotsac, I have identified
one point, as I have described in earlier posts, and the latest posted V4.4 version in the archive stops
well short of this.