martin-helmich / libcintelhex Goto Github PK

View Code? Open in Web Editor NEW

33.0 7.0 15.0 769 KB

A C library for parsing Intel HEX files.

License: GNU Lesser General Public License v3.0

C 78.65% C++ 21.35%

libcintelhex's Introduction

cIntelHex - A C library for parsing Intel HEX files

Authors

Martin Helmich [email protected]
Oliver Erxleben [email protected]

University of Applied Sciences Osnabrück

André Colomb [email protected]

License

This program is free software: you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.

You should have received a copy of the GNU Lesser General Public License along with this program. If not, see http://www.gnu.org/licenses/.

Synopsis

libcintelhex is a C library for parsing Intel HEX files and mapping their binary contents into application or device memory.

Installation

Requirements

libcintelhex has no requirements besides a halfway recent GCC and a C standard library. Compilation on Windows with MinGW has also reported to be successful, building with Clang is still problematic, though.

When cloning from Git, you will also need autoreconf to generate the build system.

Compilation

Installation as usual:

autoreconf -i
./configure
make
make install

Usage

After installation, include cintelhex.h and add -lcintelhex to your linker flags.

Reading Intel HEX data

This library can parse Intel HEX data either from an input file or directly from a given string:

ihex_recordset_t* r1 = ihex_rs_from_file("my_filename");

char* input = ":1a01000021A4B2Fe...";
ihex_recordset_t* r2 = ihex_rs_from_string(input);

Applying Intel HEX data

Intel HEX data can be copied to any region in memory (either somewhere in RAM, but also to mapped memory regions of hardware devices):

void* dst = malloc(8192); // Allocate target region.
int   r   = ihex_mem_copy(rs, dst, 8192,
    IHEX_WIDTH_32BIT, IHEX_ORDER_BIGENDIAN); // Copy data to target region.

if (r == 0) printf("All is well.\n");
else return r;

libcintelhex's People

Contributors

Stargazers

Watchers

Forkers

basm anatol acolomb martonmiklos mkatz60 yyzreal sndnvaps lnming distant-one tomaszosypinski smarttowel ccccmagicboy2022 genoswitch daeheun

libcintelhex's Issues

Memory of record sets is never freed

There is no API call to free the memory associated with an ihex_recordset_t object.

I propose a new API function ihex_close(rs) / ihex_free(rs) / ihex_cleanup(rs). Some of the cleanup code in ihex_rs_from_string() should be reusable here. The file test_copy.c also contains a suitable implementation in mock_recordset_free().

This is low priority for me, but as time permits I will try to provide an implementation.

if (read(fd, c, l) != l) fails always on windows machines

ihex_parse.c, line 88:
if (read(fd, c, l) != l) fails always on windows machines, because "\r\n" will be silently translated to "\n" as the file is read.
Therefore the two length values differ and it always fails...

Why does libcintelhex need -D_POSIX?

The current build system passes -D_POSIX to the compiler, defining the _POSIX macro. Where is this needed? What does it do? There are a lot of similar macros with this prefix to enable or test for certain POSIX features, but this one seems undocumented.

Regarding the updated build system in #23, I would suggest to leave this flag out or replace it with something like AC_USE_SYSTEM_EXTENSIONS to enable newer POSIX and GNU features.

IHEX_SLA

The current implementation of libcintelhex doesn't appear to support IHEX_SLA instructions. I've got some firmware that I'd like to write to a device that makes use of this instruction. Simply ignoring IHEX_SLA doesn't work, I think I need to start writing to an address at this offset. Any chance of supporting this, or pointing me in the right direction so I can add this functionality myself?

RFC: Common code for iterating through a record set

As discussed in #19, it should be avoided to have lots of duplicate code to iterate through an ihex_recordset_t structure to process the data.

I propose an iterator function as outlined in commit acolomb/libcintelhex@9125ca3, kindly asking for comments.

LICENSE

Hello. Thank you for good library!

I try write simple programmator/bootloder for AVR microcontrollers.
But use GPLv3 for it I think bad idea.

Maybe change licence to more liberally for your library. I have plan
fix your library for static linking (for get rid of unnecessary dependencies).
It may BSD or simular.

What is your opinion on all this?

Thank you.

Copying data beyond given target memory range

When using ihex_mem_copy(), there are several possible memory access bugs involved.

The base address of the record is checked to lie within the target memory range specified by the dst and n parameters. However, the record length in bytes is not considered, so writing the whole record data may end up past the end of allocated memory (verified with valgrind).

In addition, record data is always copied in four-byte blocks, caused by the use of uint32_t pointers. This may lead to writing even more data than specified in the record length, in case the latter was not a multiple of four.

To correct these issues, care needs to be taken to still correctly implement endianness / byte order swapping. So far I have a simple fix to avoid the first memory access violation, but a better copying approach is needed. I will update this issue with a pull request once I have a first draft.

Byte-order handling works only on Little-Endian architectures

The current code in ihex_mem_copy() assumes that bytes in a 16- or 32-bit word have to be swapped when the target is specified as big-endian. This is only true for little-endian host architectures like x86 where the library is compiled.

I propose to add compile-time checking of the host endianness to the configure script to make it work on big-endian CPUs like some ARM. However, I have yet to find a portable way of doing so.

A specifier for IHEX_ORDER_NATIVE would also be of benefit to disable byte-swapping completely, independent of the host endianness.

Errors when using ihex_rs_from_file()

Hello,
I was using American Fuzzy Lop (afl-fuzz) to fuzz input to a modified version of test program that calls ihex_rs_from_file(argv[1]) and found these input files cause the program to exit unexpectedly.
Is fixing these crashes something you're interested in? The input files can be found here: https://github.com/rwhitworth/libcintelhex-fuzz.

Let me know if I can provide any more information to help narrow down this issue.