giggler g

CRC module, K60 problems

Discussion created by giggler g on Mar 27, 2013
Latest reply on Apr 25, 2013 by Pedro Augusto Panecatl Salas



Thought I'd log with a question my findings about the CRC module in the hope it might save someone else time.  I am using the pre-release silicon as PK60N512VMD100.  I checked the datasheet/reference manuals and no changes seem to have been made for release parts so I assume it's the same.


When generating a 16bit CRC we are told to write to the 16bit registers, i.e.





This works fine and actually is rehashed code from MQX (crc_kn.c).


Does it not make you wonder why MQX code does a byte swap with shifts when they can transpose the write data in hardware?


To remove the byteswap which is just overhead you should be able to specify CRC_CTRL_TOT_SHIFT = 3 where bytes only are swapped.


Then the code fails to produce valid CRC's, datasheet says: Types of transpose


Figure 31-7. Transpose type 11


For 8-bit and 16-bit write accesses to the CRC data register, the

data is transposed with zeros on the unused byte or bytes

(taking 32 bits as a whole), but the CRC is calculated on the

valid byte(s) only. When reading the CRC data register for a

16-bit CRC result and using transpose options 10 and 11, the

resulting value after transposition resides in the CRC[HU:HL]

fields. The user software must account for this situation when

reading the 16-bit CRC result, so reading 32 bits is preferred.


This is wrong.  It does not seem to pickup the correct data, writes to either high or low 16bit words make no difference.  Both yield invalid crc.




What I found is writing as 32words work with transposed bytes as:


uint8_t  *pCRCBytes=(uint8_t*)&(crc->CRC);
uint32_tlengthWords,remainder=messageLength % 4;



for(i=0;i<lengthWords;i++) {




/* Any remainder bytes to include in calculation? */

for(i=0;i<remainder;i++) {

*pCRCBytes++ = message[(messageLength-remainder)+i];