search

vdudouyt / stm8flash

program your stm8 devices with SWIM/stlinkv(1,2)
GNU General Public License v2.0
403 stars 183 forks source link

Fix SRec S5 field handling #118

Closed msalau closed 2 years ago

msalau commented 5 years ago

S5 records has 2-byte long address field that contain number of data records expected in the file, but address is read as a 4-byte long hex value, which results in checksum becoming part of the address read. This gives incorrect number of data records and as a result the tools rejects any file with S5 records.

spth commented 4 years ago

Has anyone else tested this?

msalau commented 4 years ago

Hi @spth You can generate a sample SREC-file to test the fix using the following command: srec_cat -generate 0x0000 4 -constant 0x42 -o - -motorola

$ srec_cat -generate 0x0000 4 -constant 0x42 -o - -motorola
S0220000687474703A2F2F737265636F72642E736F75726365666F7267652E6E65742F1D
S107000042424242F0
S5030001FB
$
spth commented 4 years ago

Thanks. Since you seem familiar with SRec, could you also implement checking the checksum in srec_read?

msalau commented 2 years ago

@spth Done :) Besides handling of S5 records and checksum verification, handling of S2 and S3 records was fixed. Some parts of the srec_read() function were expecting address to be exactly 2 bytes long and thus worked correctly only with S1 records.

Here is a test srec file which exercise all useful record types (S1, S2, S3 and S5):

S0220000687474703A2F2F737265636F72642E736F75726365666F7267652E6E65742F1D
S10780004242424270
S208008004424242426B
S309000080084242424266
S5030003F9