S-19 Patching does not seem to work

[woj]

Hi,

I wanted to test this feature, I loaded the .s19 file, confirmed that I indeed want to patch the bin file, but nothing happened, no error message either. This is the contents of the file I tried (created by a tool I wrote, but I did check it carefully, nothing seems to be wrong with it):

Code: Select all

S0120000313656414443457874656E73696F6EBD
S1074B720359035A89
S1055C91F8A07A
S105C8F9D86105
S126D8618600B7103086064A26FDB61031B703598605B7103086064A26FDB61031B7035A7E983D6D
S104EEC10050
S104EECD0044
S5030006F9
S9030000FF

EDIT: OK, before anybody starts looking into this I think I know where it goes wrong, I calculated the checksums wrong

EDIT2: Well, it was a problem, now it works, well almost, the patch below now causes TP to crash:

Code: Select all

S10563600352E2
S10563830350C1
S10590BAD77069
S12CD76CF3D706C818CEEF14CE034F18EC01ED0118EC03ED03CED76C18CE0FF020228CD770274DA60018A800819F
S14CD796260508180820EDCE034FCC10BDED01CC113BED032030B610263684BFB710268CD770271EE600533C8616BD91C58602BD91C5380818088655B7103A86AAB7103A20DD32B710267E506304
S5030005F7
S9030000FC

My diagnosis is that the 5-th record is too long (length field 4C). If I split it in two shorter ones, it works...

[Mangus]

I'll take a look as soon as I have a bit of time. Thanks for reporting this.

[Mangus]

I can't get anything to crash with either of your patches. However, your "crashing" patch also has a bad checksum.

I've added notification of the patch results. You'll now get a message telling you whether the patch succeeded or failed. Shortly I'll add more information for failure cases as well.

[woj]

Sorry to say that Mark, but according to the best of my checks the checksums in this second snippet are OK (see below). So perhaps you could check your checksum caclucation routines again

Re crashing, this may of course depend on the the bin file being patched...

Code: Select all

$ srec_info badpatch.s19 
Format: Motorola S-Record
srec_info: badpatch.s19: 1: warning: no header record
Execution Start Address: 00000000
Data:   6360 - 6361
        6383 - 6384
        90BA - 90BB
        D76C - D794
        D796 - D7DE

[Mangus]

Can you zip up and email me the bin you're patching, along with any S19 files you'd like me to test?

Thanks.

[Mangus]

Your crashing S19 file doesn't conform to the s-record spec. I've fixed (for the next build) my s-record importer to better catch malformed S19 files (and handle unusually large data payloads, just for fun). Meanwhile, you should fix your file.

Here's more info on the file structure:
http://www.amelek.gda.pl/avr/uisp/srecord.htm

(Note - S-records generally have a max data payload of 64 bytes. 16 and 32 bytes are standard. Your crashing record has 0x49 bytes of data.)

[woj]

Your crashing S19 file doesn't conform to the s-record spec. I've fixed (for the next build) my s-record importer to better catch malformed S19 files (and handle unusually large data payloads, just for fun). Meanwhile, you should fix your file.

Here's more info on the file structure:
http://www.amelek.gda.pl/avr/uisp/srecord.htm

(Note - S-records generally have a max data payload of 64 bytes. 16 and 32 bytes are standard. Your crashing record has 0x49 bytes of data.)

Well, that's what I already suspected in post #1. On the web-page you quoted it states:

"This is the only place that a 78-byte limit on total record length or 64-byte limit on data length is documented. These values shouldn't be trusted for the general case. "

Moreover, it also says:

"If you write code to convert S-Records, you should always assume that a record can be as long as 514 (decimal) characters in length (255 * 2 = 510, plus 4 characters for the type and count fields), plus any terminating character(s). That is, in establishing an input buffer in C, you would declare it to be an array of 515 chars, thus leaving room for the terminating null character. "

Anyhow, many thanks for looking into this