EPROM programming problem, HC705C8

[cwt]

I have a requirement to support an old product using the HC705C8. I have the LST file and the S19 file. When I try programming, it stops at a point where it is trying to rewrite a memory location. The problem piece out of the LST file is :

09D5 CD0B82    1207  DD4:      JSR    EEREAD         ; READ BYTE FROM EEPROM
09D8 D70100    1208            STA    $0100,X        ; THE FOLLOWING GIVES WORD OFFSET
09D9           1209            ORG    $-2
09D9 0020      1210            DW     {CAPBUF-CAPSTRT}
09DB 5C        1211            INCX
09DC 3AD4      1212            DEC    COUNT
09DE 26F5      1213            BNE    DD4            ; LOOP FOR NEXT DIGIT

At line 1209, the ORG statement is setting the memory location pointer back by 2, but locations 09D8, 09D9 & 09DA have already been used by 'STA $0100,X'.
I do not understand the point of the ORG  $-2   in the middle of a long file.

The originator of this code is no longer available.   Can anyone suggest the reason for this?  Is it a security 'trick'?

Bill

[cwt]

Tony,

I tried a different programming s/w + h/w combination (a product made by Hi-Lo Systems) and this accepted the original S19 file with no problems.  So issue is resolved but I am left with some unanswered questions. I'll live with this because I can't afford the time to investigate such an old product.

Thanks for your help.

Bill

[tonyp]

The reason for doing this isn't clear (at least, to me), and I don't see it as any kind of security trick because the problem it creates is trivial to resolve.  All this does is overwrite the offset part of the immediately preceding STA instruction with a different value (from $0100 to $0020).  The net result is that the S19 created will have duplicate data for the same address possibly causing problems with certain programmers that will choke on this.

Depending on how smart the programmer software is this may confuse it.  Some programmers will load the whole file in memory, create a 'final' memory image of what to burn to the device and then start the burning process.  Others, will burn as they read the file, and they will complain when they try to reprogram an already programmed location.

The solution is simple.

Make a copy of the S19 file and edit it with a plain text editor.  Find the S1 record that contains this offset and go write 0020 over the 0100 (of the STA $100,x instruction).  This will still have an overwrite in the S19 file but your programmer may not complain as the overwriting value is the same as the previous one.  If it does, more work is needed.  You must remove the extra two bytes from wherever they appear (normally next S19 record, unless the S19 file has been re-sorted).

This should be very easy if you're lucky enough that the two bytes (of the DW directive) are in an S1 record all by themselves (just delete the whole S1 line).  If not, you need to also edit the S1 record's length byte after you delete the four hex digits from the S19 ASCII file.

In any case, if your programmer refuses to process the edited S19 file due to CRC errors (instead of simply giving a warning and proceeding), then you'll also need to update the CRC of the related S1 record(s).  This is the final byte.

For details about the exact format of the S19 file you can have a look here: SREC (file format) - Wikipedia, the free encyclopedia

(If you still can't figure it out, I could help with the conversion if you send me the S19 file and the above snippet from the LST file.

You should probably check the S19 file with this tool from P&E (S_TEST) found here: P&E Microcomputer Systems in case there are more than one occurrence of this issue in your file.

Hope this helps.

[cwt]

Tony,

Thanks for this useful input.  I think the programmer I am using is checking byte by byte.  Maybe some other programmer would not complain and just continue.  If this is just a 'typing error '  in the source file then the assembler would not pick it up and a certain type of programmer might not complain. The 2 lines - ORG and  DW don't seam to do anything and could be deleted.  Given all this the original developer may never have realized this problem was ever in the source code.

My next plan is to delete these 2 lines from the .ASM file and re-assemble it to get a new .S19

Regards

Bill

[tonyp]

Oh well, if you've had the source file all along, editing it and re-assembling was the obvious choice.  I thought you only had the S19.  Even having the listing in digital form (instead of just a printout) would allow to go back to the source, edit, and re-assemble.

However, be sure to do it right.  You should not just delete the two lines.  You also need to change the $100,x to {CAPBUF-CAPSTRT},x to have the final effective address of the original.

Good luck.