nowECC 2.21 failed if HEX does not start at @0x0

Jiri,

I believe there's some alignment requirement that's implicit in the ECC scheme,  since for efficiency reasons ECC is implemented on units of 64-bits at a time.   Are any of the records in the hex file that you are having trouble with not aligned to a 64-bit boundary.  If so that may be the issue.

Hi Anthony,

thanks for your comment!

I have not got the error message: "Error 57 - Address should be aligned on 64 bit boundary". The HEX is created by GCC toolchain - command line:

objcopy -O ihex program.elf program.hex

A data record of the produced HEX consists of 16 data Bytes and 16-bit address.

nowECC is called by

nowecc -i program.hex -F021 16M_ADD -r4 -a -o program_ECC.hex

By the way, if nowECC does not complain and an ECC section is appended, this ECC section in the HEX file consists of 32 data Bytes.

Cheers, Jiri

Hi Jiri,

Is it possible for you to send a test .hex file that gives this error - Sorry I don't actually use nowecc much and am not proficient but I think we can figure out what's going on with it by doing some debug,

-Anthony

Hello Anthony,

I have sent an example to your email - I am not allowed to share this code in public.

Anyway further investigation results will be made public on this forum thread.

Thanks and best regards,

Jiri

Hi Jiri,

Ok I am 'basically' able to reproduce the error.

I don't get the error about ignoring / root name but I get the error about record type 5.

generate HEX
generate HEX with ECC appended
This is nowECC Version 2.21
Mapping: F021-16MB

Error 40  - Invalid record type 05 found in Intel input file
gmake: *** [gcc_led_rti_ECC.hex] Error 40

Not sure if the difference is significant or not yet anyway I think I can use this and bring up a debug session on nowECC if needed to figure out what's going on.

Hi Jiri,

Sent you some details privately - but I can confirm that nowECC only supports record types 0,1,2, and 4 based on the source code.  

Short term solution would be to figure out a way to make the GNU hex utility avoid record type 5 if this is possible. 
 

Hello Anthony,

the message about ignoring is being saved  into nowECC.log even if there is shown "No error" by nowECC if called in a console.

I absolutely agree - let us ignore the ignoring warning ;-)

Thanks and best regards,

Jiri

Hi Jiri,

Looking more at the intel hex format spec (thanks to Wikipedia http://en.wikipedia.org/wiki/Intel_HEX) - the record type 5 seems to be just an 'entry point' record, it should be just loaded into the PC by a loader if you actually wanted to start running the program. 

Trying to find it in the output to confirm, but if this is the case it would seem that a fix might be to just ignore this record (perhaps printing a warning that it's doing so) because nowECC isn't a loader anyway.

Wondering what your perspective is on this?

Best Regards,
Anthony

Hello Anthony,

thanks for your intensive support!

You are right - a workaround regarding ENTRY point as you have described is the sufficient solution at the moment (and our current application). It would be nice if nowECC can handle this behaviour but I understand that you are not going to support nowECC because its function is now implemented within CGT / CCS environment.

Thanks once again,

Best regards, Jiri

Hi Anthony,

thanks for your clarification a lot - sounds good!

<offtopic>

It is a shame that nowFlash did not keep alive as well - for some purpose it was a simple and straight-forward tool.

</offtopic>

Best regards, Jiri