Generating check sum for 8051 code

Hi,

I am trying to use the Keil specified steps in http://www.keil.com/support/docs/494.htm to generate checksum after I compile the code. I get following messages from Keil and wonder what I am doing wrong?

Program Size: data=50.5 xdata=0 code=2675 creating hex file from "..\output\bit_adc"...
User command #1: "C:\Documents and Settings\fsiavoshi\My Documents\AC_Smart\Software\PhaseProc\BIT_ADC\source\genchksum.bat"
C:\Documents and Settings\fsiavoshi\My Documents\AC_Smart\Software\PhaseProc\BIT_ADC\project>hex2bin bit_adc.hex /Q The system cannot execute the specified program.
C:\Documents and Settings\fsiavoshi\My Documents\AC_Smart\Software\PhaseProc\BIT_ADC\project>check8 bit_adc.bin /s0x0000 /e0x7FFE /p0x7FFF /v0x80 The system cannot execute the specified program.
C:\Documents and Settings\fsiavoshi\My Documents\AC_Smart\Software\PhaseProc\BIT_ADC\project>bin2hex bit_adc.bin a.hex /Q The system cannot execute the specified program.
"..\output\bit_adc" - 0 Error(s), 1 Warning(s).\

Please let me know.

Thanks

Parents
  • I'm not sure what your exact problems are, but I do note that you are using a directory path containing spaces. For a good many years, spaces in directory names have created lots of havoc for a lot of users, since many library functions splits the command line at every space suddenly making part of the path to the binary into parameters.

    As a general rule, you should always try to avoid spaces in directory names. Somewhere along the line, you will get hurt. If not today, then tomorrow, next week or next year. But the world is full of applications that forgets to put the paths in quotes or in other ways make sure that they don't get splitted.

  • Continuing from follow up question randomly placed in thread:
    http://www.keil.com/forum/18452/

    Note that unwritten flash memory for most processors will have the value 0xff.

    You don't need to use an absolutely placed variable for the checksum value - you can also use a code pointer set to the value 0x7ffe.

    Have you spent any time verifying the byte order for 16-bit integers in PLM/51 yet? Does it match the byte order for C51? If it doesn't, then you need to perform the compare individually for high and low byte instead of playing with a 16-bit integer.

Reply Children
No data
More questions in this forum