Hi,
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.
CRC_MemMapPtr crc=CRC_BASE_PTR;
crc->ACCESS16BIT.CRCL=BYTESWAP(data);
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:
31.3.3.1 Types of transpose
Figure 31-7. Transpose type 11
NOTE
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.
Resolve:
What I found is writing as 32words work with transposed bytes as:
| uint32_t | *message32=(uint32_t*)message; |
| uint8_t | *pCRCBytes=(uint8_t*)&(crc->CRC); |
| uint32_t | lengthWords,remainder=messageLength % 4; |
lengthWords=messageLength>>2;
for(i=0;i<lengthWords;i++) {
}
/* Any remainder bytes to include in calculation? */
for(i=0;i<remainder;i++) {
| *pCRCBytes++ = message[(messageLength-remainder)+i]; |
}
Regards,
dc
