Re: [avr-libc-dev] XMEGA hardware CRC calculation

[Bob Paddock]

>> that precalculates the CRC Magic Number to put into the last three
>> bytes of the application space.
>> That way a good CRC will always have a constant value.
>>  Be aware that the XMega CRC Range calculation does not work in
>> revision prior to J; that don't seem to exist yet.

> I realized that that code doesn't calculate
> a CRC but something resembling a CRC.

Yes.  It looks more like what the old Microware OS9 system did, a type of hash.

Reading Polynomials over Galois Fields tend to makes my eyes glaze
over, so I'd like to find a math guru that could tell us just how
valid this XMega calculation truly might be.  Some home made CRCs are
complete crap, where the mathematical properties work only over very
small number of bits in a block.

> To make it short: you can't append the calculated 3 bytes at the end of
> your app because you will never have a constant value when checking it
> with XMEGA CRC function.
>
> Maybe I'm wrong but if I remember well, I did all the test I could to
> have that CRC work properly but without success.

For at least standard CRCs if you store the inverse of the calculated CRC,
stored in least significant byte to most significant byte order,
 then calculate that value as just more data bytes (three in the Xmega case).
A good CRC will give a constant 'Magic Number'.
For 16-bit CRC's 0xF0B8 and 0x1D0F are popular 'Magic Number' results,
depending on the shift direction.

For this to work, on the possibly invalid assumption of standard CRC
processes, in the XMega, you need to calculate the
CRC for the application section minus the last three bytes, in an
external program.  The put the resultant three bytes as the
last three bytes in the XMega application space.

See this thread on AVRFreaks for some of the needed code for the
external program.
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=80405

> I can supply some code if someone needs it to make further test.

I'd like to see it.

> Would be a nice thing to fix this issue. Atmel wasn't able to help me
> more than this.

>> revision prior to J; that don't seem to exist yet.

> P.S. The last ATXMEGA128A1 die is revision H you were wrongly referring
> to datasheet revision J.

I was referring to die revision J.  That is what Atmel said they would
fix the CRC Rage problem in.

> I strongly hope that with the next die release
> of XMEGA A1 some errors will be fixed (XMEGA A1 datasheets revision M
> reports 42 known problems!).

I agree.  It is really frustrating that they don't fix problems for
years at a time.
I like the XMega for the most part, but I really need a functioning A/D.




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