S19 File Loading

[DL84]

Hi all -

Only saw a few posts listed that reference these files so thought I would start a new one.

I've got an application where all I want to do is take an S19 file, and upload it via COM2 serial port to a microcontroller.  I can't say I have much experience with file management in labVIEW, or this file format in general, so any help you can give would help out!

As I understand it, and I could be way off, an s19 has lots of lines of code, each line a different S# record with count, address, data, checksum info...thats about it.  I am not responsible for creating the S19, just loading it so to say.  Sort of like a large batch file as it goes line to line, just placing a HEX value into a memory address.

LabVIEW will be replacing an old DOS program that we have used for years,   I will not know the details till Wednesday about which micro we are using, but I'd assume that wouldn't change protocol too much.  A generic design could be made, and modified depending on how to upload to that specific chip.  I do know that most of the DOS programs we are using for s19 files are not backward compatible, so like I said a generic one would be great.  If all the operator had to do was drag a new s19 file into the appropriate folder, and labview gave the option of which file from that directory...that would be perfect.

If no one has used an app like this before they would mind sharing, maybe a few pointers could be offered?

Thanks all!

[tbd]

Hi leachdor,

---

... all I want to do is take an S19 file, and upload it via COM2 serial port to a microcontroller.

... LabVIEW will be replacing an old DOS program that we have used for years...

---

      I don't have any experience with this specific file format, though, according to this (found via wiki) reading S19 and extracting address/data-blocks will not be hard - see attached VI.   However you read the S19 files, that part of your program ought to be reuasable.

How to talk to the microcontroller (on COM2), in what format it will expect data, and how to make that part of the program generic?  I guess that's unknown at this point(?)  Hopefully you will have an "Interface Control Document" for the microcontroller-device, or can scratch-up the source code for the old DOS program.

Cheers.

[DL84]

That parsing application is a neat one.  I've started testing with it to see if I could use parts for my project but its coming up with an error.

s19 check-sum problem at line #56 of the file x.s19
expected: 0x4
found...: 0x04

I'm not sure what the problem is with it is, it fills the array properly with every line until it reaches that line 56.   Looking at the s19 in a text editor it doesn't seem as though there are any syntax problems in relation to the other lines....here is what is on that line...

S113FB50240ACE0077583A54861EA7015C1C008004

If I was to remove the 0 to create what labview would expect, it would deform the syntax of the line....any ideas why this error is popping up?

[tbd]

> any ideas why this error is popping up?
Yup - it's a bug. 

The logic is building an expected Check-sum string which should always be two characters, but the "Number To Hexadecimal String" doesn't have its "width" input wired, so it builds a one character string for the hex value "0x4".  This is fixed in the attached VI - I also added a check for last record to suppress another faux-error at EOF (end of file).

Cheers!

[DL84]

Similar error...different line.

S19 Check-sum problem at line# 125 of the file x.s19
expected: 0x4A
found...:0x3D

That one shows two characters though in what was expected and found...

[tbd]

hi leachdor,

      Assuming the S19 file is constructed correctly, it's a bug in the check-sum calc which accumulates a sum in an 8-bit register.  The S19-specs said to use a 16-bit accumulator then AND with 0xFF - but I didn't.  The following change might fix this.  If not, please post line# 125!

WAS:

(probably) SHOULD BE:

Cheers.

(P.S Can't send LV 6.1 version at the moment...)

Message Edited by tbd on 03-22-2007 12:58 PM

[DL84]

Hmm that didn't help, in fact after making that modification it tripped out on line 1.

Here is the end of the s19 where it is tripping and the surrounding lines...

.
.
.
Line 120: S113FF50FC74FD55FD6DFC74FD42FDA2FC45FD5590
Line 121:  S113FF60F0E0D060B010A0C00001400000000644E2
Line 122:  S10BFF703F200D0A4F4B0D0A5E
Line 123:  S105FFB907013A
Line 124:  S106FFBB0000003F
Line 125:  S105FFBE93603D
Line 126:  S113FFD6FECEF800F800F800F800F800F800F80083
Line 127:  S113FFE6F800FE16F800F800F800F800F800F8002B
Line 128:  S10DFFF6F800F800F800F800F80025
Line 129:  S9030000FC

Line 129 is the end of this S19.

Thanks for the all the help!

[tbd]

Hi leachdor,

      I hate to "go out on a limb", but it looks like there's a legitimate checksum error on that line.  I made the change pictured above and get exactly the same results.  It's a very short line - something like 5 values are being summed.  If you can explain why the checksum should be "3D" and not "4A" I'll fix it!

I'd leave the 8-bit solution as-is (it's simpler) but if you want to see that the 16-bit version works, it's implemented in the attached VI (back-saved to LV 7.0)  This VI includes other improvements too.  The check-"summer" was summing the "S1" bytes too - it had no negative effect because "S1" converted to hex added zero!  The last-line check is better.

Cheers!

[tbd]

follow up...

By odd coincidence, a friend recently mentioned using "S-files" at his job - and it turned out to be S19 files.  More amusing was that he'd edited a data-byte (or two) without updating the associated checksum - this was sounding so familier!

On reviewing the VI last attached, I found a bug was introduced with the "improvements" (wrong address is reported by Util.File.S19.Parse2.vi).  Here it is again, (in LV 8.2.) in case somebody eventually stumbles across this thread.

Cheers!

[DL84]

He changed the values without the checksum changing?

There isn't much to update on, I've been waiting on a response from the engineer that programmed the source for that S19 about the checksum problem.  If anything it is parsing correctly, I may just remove the check of the checksum, and once the array is full - just send to the micro line by line via the value at each array location.

I am curious about this that your friend did though...if he is making modifications that don't change the checksum, maybe something like that has been done to ours?