> i have updated the "jtag" and "pyjtag" CVS modules. > this does hopefully fix the nasty verification error, altough it will be a bit slower now... > (the other mem read function sometimes reports the first word wrong, if that bug is fixed we could switch back to the faster read...) > > -R, --ramsize option added to jtag.py so that the blocksize for flashprogramming can be set to larger values (or smaller for the devices > with only 128B RAM). it improved the flash write speed a bit, but the verify is using up most of the time anyway so that it's not much of an > advantage. > > i tested it with some devices (F1121, F123, F148, F449) and i hope it works with your devices too :-) > > chris >
Does this mean that the problem was that the memory was sometimes being read back incorrectly, rather than being programmed incorrectly? 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? 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. 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. 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) ? 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 :-) mvh. David.
