AVR-Chat

could it be a byte order problem in the computed CRC or the polynomial?

--- In AVR-Chat@yahoogroups.com, Dede <dewa27@...> wrote:

>
> 
> J
> 
> 
> ----- Original Message -----
> From: wagnerj@...
> Sent: 05 May 2010 11:13
> To: AVR-Chat@yahoogroups.com
> Subject: Re: [AVR-Chat] CRC using IAR compiler
> 
>  
> > I'm using the IAR compiler V5.11 or 5.12 and need to use the feature
>  > that has the linker write a CRC in the last two bytes of the executable.
>  >
>  > I got the linker to write the CRC and I am able to read it back. The
>  > problem is, I can't manage to compute the same one. I have tried
>  > several different routines to generate the CRC and they agree with
>  > each other, but not with what IAR computes. In each case, it is
>  > supposed to be a CRC 16 of the CCITT variety with 0x1021 as the
>  > polynomial.
>  >
>  > Has anyone gotten this to work? Is there some sample code somewhere
>  > that has been shown to work with the IAR computed CRC?
>  >
>  > Thanks.
>  >
> 
>  PS - sorry for misspelling your name!
> 
>  Jim Wagner
> 
> 
> Reply to sender | Reply to group | 
> 
> [The entire original message is not included]
> 
> [Non-text portions of this message have been removed]
>

could it be a byte order problem in the computed CRC or the polynomial?

--- In AVR-Chat@yahoogroups.com, Dede <dewa27@...> wrote:

>
> 
> J
> 
> 
> ----- Original Message -----
> From: wagnerj@...
> Sent: 05 May 2010 11:13
> To: AVR-Chat@yahoogroups.com
> Subject: Re: [AVR-Chat] CRC using IAR compiler
> 
>  
> > I'm using the IAR compiler V5.11 or 5.12 and need to use the feature
>  > that has the linker write a CRC in the last two bytes of the executable.
>  >
>  > I got the linker to write the CRC and I am able to read it back. The
>  > problem is, I can't manage to compute the same one. I have tried
>  > several different routines to generate the CRC and they agree with
>  > each other, but not with what IAR computes. In each case, it is
>  > supposed to be a CRC 16 of the CCITT variety with 0x1021 as the
>  > polynomial.
>  >
>  > Has anyone gotten this to work? Is there some sample code somewhere
>  > that has been shown to work with the IAR computed CRC?
>  >
>  > Thanks.
>  >
> 
>  PS - sorry for misspelling your name!
> 
>  Jim Wagner
> 
> 
> Reply to sender | Reply to group | 
> 
> [The entire original message is not included]
> 
> [Non-text portions of this message have been removed]
>

J

----- Original Message -----
From: wagnerj@proaxis.com
Sent: 05 May 2010 11:13
To: AVR-Chat@yahoogroups.com
Subject: Re: [AVR-Chat] CRC using IAR compiler

 
> I'm using the IAR compiler V5.11 or 5.12 and need to use the feature
 > that has the linker write a CRC in the last two bytes of the executable.
 >
 > I got the linker to write the CRC and I am able to read it back. The
 > problem is, I can't manage to compute the same one. I have tried
 > several different routines to generate the CRC and they agree with
 > each other, but not with what IAR computes. In each case, it is
 > supposed to be a CRC 16 of the CCITT variety with 0x1021 as the
 > polynomial.
 >
 > Has anyone gotten this to work? Is there some sample code somewhere
 > that has been shown to work with the IAR computed CRC?
 >
 > Thanks.
 >

 PS - sorry for misspelling your name!

 Jim Wagner


Reply to sender | Reply to group | 

[The entire original message is not included]

[Non-text portions of this message have been removed]

might be!

Jim Wagner
On Jun 13, 2010, at 9:04 PM, stevec wrote:

>
> could it be a byte order problem in the computed CRC or the  
> polynomial?
>
> --- In AVR-Chat@yahoogroups.com, Dede <dewa27@...> wrote:
> >
> >
> > J
> >
> >
> > ----- Original Message -----
> > From: wagnerj@...
> > Sent: 05 May 2010 11:13
> > To: AVR-Chat@yahoogroups.com
> > Subject: Re: [AVR-Chat] CRC using IAR compiler
> >
> >
> > > I'm using the IAR compiler V5.11 or 5.12 and need to use the  
> feature
> > > that has the linker write a CRC in the last two bytes of the  
> executable.
> > >
> > > I got the linker to write the CRC and I am able to read it back.  
> The
> > > problem is, I can't manage to compute the same one. I have tried
> > > several different routines to generate the CRC and they agree with
> > > each other, but not with what IAR computes. In each case, it is
> > > supposed to be a CRC 16 of the CCITT variety with 0x1021 as the
> > > polynomial.
> > >
> > > Has anyone gotten this to work? Is there some sample code  
> somewhere
> > > that has been shown to work with the IAR computed CRC?
> > >
> > > Thanks.
> > >
> >
> > PS - sorry for misspelling your name!
> >
> > Jim Wagner
> >
> >
> > Reply to sender | Reply to group |
> >
> > [The entire original message is not included]
> >
> > [Non-text portions of this message have been removed]
> >
>
>
> 



[Non-text portions of this message have been removed]

On Sun, 13 Jun 2010, Jim Wagner wrote:

>> could it be a byte order problem in the computed CRC or the
>> polynomial?
> might be!
> Jim Wagner

This thread has been active for a while now.
Although CRC is a superior checksum scheme,
considering the effort this seems to be, I was
curious why you specifically want a CRC
checksum, as opposed to a simpler checksum
scheme?

Best,
Marc

On Thu, Jun 17, 2010 at 05:22:42PM +0200, Marc R.J. Brevoort wrote:
> On Sun, 13 Jun 2010, Jim Wagner wrote:
> 
> >> could it be a byte order problem in the computed CRC or the
> >> polynomial?
> 
> This thread has been active for a while now. Although CRC is a
> superior checksum scheme, considering the effort this seems to be, I
> was curious why you specifically want a CRC checksum, as opposed to a
> simpler checksum scheme?

I haven't been in this thread, but have traveled this road. Very often
a number claimed to be a CRC is generated by an outside source that one
has no control over. Therefore one has to go about trying to find an
algorithm to reproduce the same results.

No matter one supposedly knows the polynomial, not everyone applies it
the same. Some start the summing with zero, others with -1.

At least one school of thought believes the last N bits shifted into a
CRC-N polynomial are not fully represented. Their solution is to "close"
the calculation by feeding a known value such as -1 (N bits in size)
in to the CRC. Once this is done one can not append more data, hence its
a closing act.

-- 
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

This has been active because I got pulled away from it for a while.   
Its kind of a back burner task for me.

I did get back to it yesterday and here's what I found out.

1.  I was not running the "slow" CRC twice with 0 to flush out the  
result.  After doing this, I do compute a CRC that agrees with what  
IAR generates.

2.  It only works for me in the emulator, not when I run in the  
debugger.  I suspect that's because I have some funky -D and -Z  
settings in my build comand and the CRC may not be computed for the  
same range in the complier as in my code.  I haven't had the time to  
get back to that issue yet.

On Jun 17, 2010, at 8:22 AM, Marc R.J. Brevoort wrote:

> On Sun, 13 Jun 2010, Jim Wagner wrote:
>
>>> could it be a byte order problem in the computed CRC or the
>>> polynomial?
>> might be!
>> Jim Wagner
>
> This thread has been active for a while now.
> Although CRC is a superior checksum scheme,
> considering the effort this seems to be, I was
> curious why you specifically want a CRC
> checksum, as opposed to a simpler checksum
> scheme?
>
> Best,
> Marc
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

>
>
> > This thread has been active for a while now. Although CRC is a
> > superior checksum scheme, considering the effort this seems to be, I
> > was curious why you specifically want a CRC checksum, as opposed to a
> > simpler checksum scheme?
>

A checksum will have the same value regardless of the order of the bytes,
where a CRC will have a different value if the order of the same bytes is
different.


>
> No matter one supposedly knows the polynomial, not everyone applies it
> the same. Some start the summing with zero, others with -1.
>

A CRC initialized to zero will miss inserted leading zeros, which is why
initialization to -1 is preferred.

Even if you are not using C++ this is still worth a read, as well as the
links within:

http://www.boost.org/doc/libs/1_34_0/libs/crc/index.html


-- 
http://blog.softwaresafety.net/
http://www.designer-iii.com/
http://www.wearablesmartsensors.com/


[Non-text portions of this message have been removed]