| T O P I C R E V I E W |
| grog_polymer |
Posted - 01/05/2007 : 12:02:32
I was programming a 27C256. The hex file last address specified in the hex file was below the highest address available. Verification failed at the next address. Message was like - adress blah found FF expect 00
Regards,
Greg |
| 6 L A T E S T R E P L I E S (Newest First) |
| grog_polymer |
Posted - 01/09/2007 : 20:18:54
support have been emailed as requested.
Regards,
Greg |
| mcumall |
Posted - 01/09/2007 : 12:32:32
OK. That is the software bug I believe.If so, then it will be fixed in the next software release.
Can you send an hex file to support@mcumall.com? So that we can verify the fixes.
Thank you for your bug report. |
| grog_polymer |
Posted - 01/08/2007 : 20:26:48
Wrong - the chip was FULLY BLANK (ie. all FF) before write as I have indicated by the blank check! It appears that the write process honours the maximum address used in the hexfile BUT verify appears to compare the FF's that remain in the ROM above that address with 0.
eg
The result of a write is
data[0], data[1] ... data[max_used], FF,FF ...[Max ROM address]
...................................................^
The compare fails at this byte...........^
The error messafge said that FF did not match 0
Changing the codesize I would have to do with each ROM revision. Perhaps I could fill the write buffer with FF's beyond the last used address, OR the verification process could stop at the maximux used address which would seem smarter as it appears that the write process finishes there already!
Regards,
Greg |
| mcumall |
Posted - 01/08/2007 : 18:02:57
It seems the chip only partially blank before write. And software assumed the chip is full blank.
This can be fixed by adding another feature: let user to set the buffer length or set the buffer length to the highest address of the loaded data (hex) file. So that to avoid verify the data address greater than hex file's last address.
Also, there is a working around for current software: Create a new device by editing the devices.txt file. Copy your 27C256 line to another line. change the device name to your special name and add the CodeSize="XXXX", where the XXXX is your data length. |
| grog_polymer |
Posted - 01/08/2007 : 12:37:49
This is REALLY simple.
The ROM was blank as verified by the blank check.
The dip switches were correct and I verified that the switches were working as I had had a similar problem to one of the other users [akvgc] with dip switches not functioning.
The hex file only specified the data up to the highest byte it needed.
The ROM wrote successfully i.e. All of the data up to the last byte specified in the hex file matched ROM data.
The data in the ROM ABOVE the last address specified in the hex file was left as FF by the write process as you would expect.
Verification failed at the FIRST byte after the highest one specified in the hex file saying that 00 did not match FF.
i.e. The verification should not attempt to verify data beyond the highest address specifed in the hex file.
|
| mcumall |
Posted - 01/08/2007 : 11:47:12
Need more detailed info on your question:
1.Did you do a blank check before write?
2.Did you set the DIP switch correctly?
3.What is the exact error message you got?
4.Have you ever programmed any EPROMs successfully. |
