Hi,

Recently I found out that the -M option to set the size of the destination eeprom does not work correctly. I have an FX2 with 16kB internal ram and an external eeprom of 8kB. Hex2Bix cannot place any code in the upper 8kB of ram if I use -M 0x2000. However if I use -M 0x4000 it correctly creates a .iic file of 7.8kB which of course fits in the 8kB eeprom. Hex2Bix seems to think on occasion that the memsize is the size of the FX2 memory instead of the size of the eeprom.

Luckily Cypress released the source and I was able to find and fix the bugs in it. So here it is, the modified source and the resulting executable.

Enjoy,

Maarten Brock

 Let's try to attach the zip-file again...

 Ok, so the forum is broken too. Even though it says I can attach a zip file it does not accept it. You can download it here:

8052.com/users/maarten/Hex2bix.zip

Maarten

 -m gives the maximum address location till which firmware opcodes reside.

The code size might be less than 0x2000 (8kB) even then there is a possibility that code will reside above 0x2000. i.e. I can have a firmware 4k firmware residing from 0x2000 to 0x3000.

The main reason behind putting the default value at 0x2000 is that FX2 and earlier EZ-USB products had a internal RAM of 8k. So if a code which needs external memory is used this error will let them know. Anyway I'll have a look at your code and if needed push for a change in our DVK files.

Regards,

Anand

 The linker already can check that my code does not go beyond the size of the code space. But it cannot check for overflow of the eeprom with its C2-header and records. That is what the hex2bix should check.

 Dear brock,

FX2LP can support upto 64k EEPROM. So that is the size hex2bix will check for (limits it through the array size)

8kB is specific to your application since your application uses a 8kB EEPROM. If a check is needed for that then you'll have to introduce it. The assumption here is EEPROM will be chosen based on size of *.iic image.

Cheers,

Anand

Sure the FX2LP can support 64kB eeprom. And with my proposed change hex2bix can check that or any other eeprom size through the -m parameter. You can even use any eeprom and reserve a part of it for non-volatile data. The thing is that hex2bix is the tool that creates the .iic file and it is this tool that can - and in my opinion should - check the resulting output. As said the linker that generates the .hex file can already check the memory map of the microcontroller but it knows nothing about the FX2 special eeprom records.

It appears you prefer to validate the input instead of the output and want to use the -m for that. Nothing wrong with that except that the current hex2bix uses the -m value for BOTH checks. It assumes the eeprom has the exact same size as there is ram for code execution in the FX2. But the eeprom can be both smaller or larger than the FX2 ram.

Finally of course the eeprom is always chosen before the final version of the software. So at that time the size of the .iic file is unknown and can be guessed at best.