Zerocat Chipflasher  v0.4.3 (board-edition-1)
Flash free firmware to BIOS chips, kick the Manageability Engine.
Classes | Functions

Objects that are needed to deal with the Motorola S-record format. More...


union  tag_typeS
 Motorola S-Record Type Infos. More...


void MOT_mkline (struct tag_linedat *linedat, union tag_typeS *typeS, char *linebuf)
 This function wraps a binary payload into a Motorola S-record frame. More...
void MOT_header (char *header, char *linebuf)
 This function invokes MOT_mkline(), but initializes parameters first with apropriate header data. More...
void MOT_data (struct tag_linedat *linedat, char *linebuf)
void MOT_summary (unsigned int lines, char *linebuf)
void MOT_typeS_fillup (union tag_typeS *typeS)
 Generating and parsing a Motorola S-record line needs to have some specs available about the line in question. This function fills a struct, based on some data that can be provided during runtime, to have all specs available when needed. More...
char MOT_rxline (struct tag_xcog0 *px, unsigned int *lines, int hexmode)
 Receive and parse a line in Motorola S-Record format. This func finishes successfully after having parsed the line's checksum data, thus not evaluating any line ending characters. More...
int line_info (char file_format, int *linepos, char c, struct tag_hexdumpline *hexdumpline, struct tag_motline *motline, int hexmode)
 Helps to detect wether the byte in question is part of the line’s S-record frame or if it is part of the (binary) payload. More...
signed char MOT_addrlen (char SREC_type)
 Return the address length in bytes that corresponds to a known S-record type. More...

Detailed Description

Function Documentation

◆ line_info()

int line_info ( char  file_format,
int *  linepos,
char  c,
struct tag_hexdumpline hexdumpline,
struct tag_motline motline,
int  hexmode 
Returns 1 to indicate a payload, otherwise zero.

Definition at line 38 of file line_info.c.

◆ MOT_addrlen()

signed char MOT_addrlen ( char  SREC_type)
Returns -1 if no valid S-record type was passed as parameter.

Definition at line 38 of file MOT_addrlen.c.

◆ MOT_data()

void MOT_data ( struct tag_linedat linedat,
char *  linebuf 

Definition at line 1263 of file kick.c.

◆ MOT_header()

void MOT_header ( char *  header,
char *  linebuf 

Definition at line 1237 of file kick.c.

◆ MOT_mkline()

void MOT_mkline ( struct tag_linedat linedat,
union tag_typeS typeS,
char *  linebuf 

The result including line ending characters is stored in a buffer. The frame size (without control chars like STX/ETX) depends on the used address lenght, it is...

  • 12 chars for S1..S9,
  • 14 chars for S2..S8,
  • 16 chars for S3..S7 data records.

Inline 0xff blobs of that size (or less) should not be filtered in order to prevent additional transmission overhead when reading chip content.

Definition at line 1162 of file kick.c.

◆ MOT_rxline()

char MOT_rxline ( struct tag_xcog0 px,
unsigned int *  lines,
int  hexmode 
What about the line buffer size? Should it be set to maximum initially or shall we allocate it on the fly?

Definition at line 2678 of file kick.c.

◆ MOT_summary()

void MOT_summary ( unsigned int  lines,
char *  linebuf 

Definition at line 1280 of file kick.c.

◆ MOT_typeS_fillup()

void MOT_typeS_fillup ( union tag_typeS typeS)

Basically, we have two situations:

  1. The S-record type (member num, values 0..9) is known but other specs not. These specs will be calculated.
  2. The S-record type is unknown, but other specs like address length and type category is known. The S-record type will be calculated.

Definition at line 2481 of file kick.c.