Am 08.01.2003 09:03:05, schrieb "David Brown" <da...@westcontrol.com>: >Does this mean that the problem was that the memory was sometimes being read >back incorrectly, rather than being programmed incorrectly?
yes >And does it >mean that you have two ways of reading the memory - fast and sometimes with >an error on the first word of the block, or slow with no errors? yes. the JTAG has an autoincrement mode which allows faster reads of blocks. >If that is the case, can I make a few suggestions that might speed up >verification? One is to try the fast read first, and only use the slow read >to re-try the words that failed. sure, but that a hack. i would prefer a clean solution. if there is no clean way we can go over to that solution ;-) >Another idea would be to use a checksum >approach rather than checking each word - have a functlet generate a crc >check of the programmed memory, and compare that to value calculated on the >PC. I have C code for a fairly fast and compact 16-bit crc check, plus the >same crc check code in python, if that would be of help or interest. actualy the MSP has a builtin PSA algorithm, you only need to apply a clock.... maybe i make an option to use that verification as option. but i like the 1:1 compare >Are these memory read changes in the python code (which I can understand, >and easily modify even on Windows), or in the C code bits (which I'd rather >not have to look at) ? C, jtag/msp430/ >Recently I've often had to use cspy to burn my chips, so I'm very glad >you've fixed the verify problem even if it makes pyjtag slower. But if we >can make it run more reliably *and* faster, then I'll be even happier :-) you can program 48kB in 8 seconds if you want.... "jtag.py -ep file.hex" this skips the "upload again" verification. the flash is programed by downloading a small program to RAM with data and execute it (because of shabby timing sources on Windows and Linux in user mode, otherwise it would be possible to write direct to flash). the downloaded code and data is verified and that "funclet" (progFlash.S in the sources) also verifies what it writes to flash. hm... i see that the result of that verification is NOT yet used. i'll change that now... chris
