<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic CRC module, K60 problems in Kinetis Microcontrollers</title>
    <link>https://community.nxp.com/t5/Kinetis-Microcontrollers/CRC-module-K60-problems/m-p/242686#M6058</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thought I'd log with a question my findings about the CRC module in the hope it might save someone else time.&amp;nbsp; I am using the pre-release silicon as PK60N512VMD100.&amp;nbsp; I checked the datasheet/reference manuals and no changes seem to have been made for release parts so I assume it's the same.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;When generating a 16bit CRC we are told to write to the 16bit registers, i.e.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;CRC_MemMapPtr crc=CRC_BASE_PTR;&lt;/P&gt;&lt;P&gt;crc-&amp;gt;ACCESS16BIT.CRCL=BYTESWAP(data);&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;This works fine and actually is rehashed code from MQX (crc_kn.c).&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Does it not make you wonder why MQX code does a byte swap with shifts when they can transpose the write data in hardware?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;To remove the byteswap which is just overhead you should be able to specify CRC_CTRL_TOT_SHIFT = 3 where bytes only are swapped.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Then the code fails to produce valid CRC's, datasheet says:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;31.3.3.1 Types of transpose&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Figure 31-7. Transpose type 11&lt;/P&gt;&lt;P&gt;NOTE&lt;/P&gt;&lt;P&gt;For 8-bit and 16-bit write accesses to the CRC data register, the&lt;/P&gt;&lt;P&gt;data is transposed with zeros on the unused byte or bytes&lt;/P&gt;&lt;P&gt;(taking 32 bits as a whole), but the CRC is calculated on the&lt;/P&gt;&lt;P&gt;valid byte(s) only. When reading the CRC data register for a&lt;/P&gt;&lt;P&gt;16-bit CRC result and using transpose options 10 and 11, the&lt;/P&gt;&lt;P&gt;resulting value after transposition resides in the CRC[HU:HL]&lt;/P&gt;&lt;P&gt;fields. The user software must account for this situation when&lt;/P&gt;&lt;P&gt;reading the 16-bit CRC result, so reading 32 bits is preferred.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;This is wrong.&amp;nbsp; It does not seem to pickup the correct data, writes to either high or low 16bit words make no difference.&amp;nbsp; Both yield invalid crc.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Resolve:&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;What I found is writing as 32words work with transposed bytes as:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;TABLE&gt;&lt;TBODY&gt;&lt;TR&gt;&lt;TD&gt;uint32_t&lt;/TD&gt;&lt;TD&gt;*message32=(uint32_t*)message;&lt;/TD&gt;&lt;/TR&gt;&lt;TR&gt;&lt;TD&gt;uint8_t&amp;nbsp; &lt;/TD&gt;&lt;TD&gt;*pCRCBytes=(uint8_t*)&amp;amp;(crc-&amp;gt;CRC);&lt;/TD&gt;&lt;/TR&gt;&lt;TR&gt;&lt;TD&gt;uint32_t&lt;/TD&gt;&lt;TD&gt;lengthWords,remainder=messageLength % 4;&lt;/TD&gt;&lt;/TR&gt;&lt;/TBODY&gt;&lt;/TABLE&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;lengthWords=messageLength&amp;gt;&amp;gt;2;&lt;/P&gt;&lt;P&gt;for(i=0;i&amp;lt;lengthWords;i++) {&lt;/P&gt;&lt;TABLE&gt;&lt;TBODY&gt;&lt;TR&gt;&lt;TD&gt;&lt;/TD&gt;&lt;TD&gt;crc-&amp;gt;CRC=message32[i];&lt;/TD&gt;&lt;/TR&gt;&lt;/TBODY&gt;&lt;/TABLE&gt;&lt;P&gt;}&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;/* Any remainder bytes to include in calculation? */&lt;/P&gt;&lt;P&gt;for(i=0;i&amp;lt;remainder;i++) {&lt;/P&gt;&lt;TABLE&gt;&lt;TBODY&gt;&lt;TR&gt;&lt;TD&gt;&lt;/TD&gt;&lt;TD&gt;*pCRCBytes++ = message[(messageLength-remainder)+i];&lt;/TD&gt;&lt;/TR&gt;&lt;/TBODY&gt;&lt;/TABLE&gt;&lt;P&gt;}&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Regards,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;dc&lt;/P&gt;&lt;P&gt;&lt;SPAN class="mce_paste_marker"&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN class="mce_paste_marker"&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Wed, 27 Mar 2013 16:44:29 GMT</pubDate>
    <dc:creator>gigglerg</dc:creator>
    <dc:date>2013-03-27T16:44:29Z</dc:date>
    <item>
      <title>CRC module, K60 problems</title>
      <link>https://community.nxp.com/t5/Kinetis-Microcontrollers/CRC-module-K60-problems/m-p/242686#M6058</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thought I'd log with a question my findings about the CRC module in the hope it might save someone else time.&amp;nbsp; I am using the pre-release silicon as PK60N512VMD100.&amp;nbsp; I checked the datasheet/reference manuals and no changes seem to have been made for release parts so I assume it's the same.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;When generating a 16bit CRC we are told to write to the 16bit registers, i.e.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;CRC_MemMapPtr crc=CRC_BASE_PTR;&lt;/P&gt;&lt;P&gt;crc-&amp;gt;ACCESS16BIT.CRCL=BYTESWAP(data);&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;This works fine and actually is rehashed code from MQX (crc_kn.c).&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Does it not make you wonder why MQX code does a byte swap with shifts when they can transpose the write data in hardware?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;To remove the byteswap which is just overhead you should be able to specify CRC_CTRL_TOT_SHIFT = 3 where bytes only are swapped.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Then the code fails to produce valid CRC's, datasheet says:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;31.3.3.1 Types of transpose&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Figure 31-7. Transpose type 11&lt;/P&gt;&lt;P&gt;NOTE&lt;/P&gt;&lt;P&gt;For 8-bit and 16-bit write accesses to the CRC data register, the&lt;/P&gt;&lt;P&gt;data is transposed with zeros on the unused byte or bytes&lt;/P&gt;&lt;P&gt;(taking 32 bits as a whole), but the CRC is calculated on the&lt;/P&gt;&lt;P&gt;valid byte(s) only. When reading the CRC data register for a&lt;/P&gt;&lt;P&gt;16-bit CRC result and using transpose options 10 and 11, the&lt;/P&gt;&lt;P&gt;resulting value after transposition resides in the CRC[HU:HL]&lt;/P&gt;&lt;P&gt;fields. The user software must account for this situation when&lt;/P&gt;&lt;P&gt;reading the 16-bit CRC result, so reading 32 bits is preferred.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;This is wrong.&amp;nbsp; It does not seem to pickup the correct data, writes to either high or low 16bit words make no difference.&amp;nbsp; Both yield invalid crc.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Resolve:&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;What I found is writing as 32words work with transposed bytes as:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;TABLE&gt;&lt;TBODY&gt;&lt;TR&gt;&lt;TD&gt;uint32_t&lt;/TD&gt;&lt;TD&gt;*message32=(uint32_t*)message;&lt;/TD&gt;&lt;/TR&gt;&lt;TR&gt;&lt;TD&gt;uint8_t&amp;nbsp; &lt;/TD&gt;&lt;TD&gt;*pCRCBytes=(uint8_t*)&amp;amp;(crc-&amp;gt;CRC);&lt;/TD&gt;&lt;/TR&gt;&lt;TR&gt;&lt;TD&gt;uint32_t&lt;/TD&gt;&lt;TD&gt;lengthWords,remainder=messageLength % 4;&lt;/TD&gt;&lt;/TR&gt;&lt;/TBODY&gt;&lt;/TABLE&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;lengthWords=messageLength&amp;gt;&amp;gt;2;&lt;/P&gt;&lt;P&gt;for(i=0;i&amp;lt;lengthWords;i++) {&lt;/P&gt;&lt;TABLE&gt;&lt;TBODY&gt;&lt;TR&gt;&lt;TD&gt;&lt;/TD&gt;&lt;TD&gt;crc-&amp;gt;CRC=message32[i];&lt;/TD&gt;&lt;/TR&gt;&lt;/TBODY&gt;&lt;/TABLE&gt;&lt;P&gt;}&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;/* Any remainder bytes to include in calculation? */&lt;/P&gt;&lt;P&gt;for(i=0;i&amp;lt;remainder;i++) {&lt;/P&gt;&lt;TABLE&gt;&lt;TBODY&gt;&lt;TR&gt;&lt;TD&gt;&lt;/TD&gt;&lt;TD&gt;*pCRCBytes++ = message[(messageLength-remainder)+i];&lt;/TD&gt;&lt;/TR&gt;&lt;/TBODY&gt;&lt;/TABLE&gt;&lt;P&gt;}&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Regards,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;dc&lt;/P&gt;&lt;P&gt;&lt;SPAN class="mce_paste_marker"&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN class="mce_paste_marker"&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 27 Mar 2013 16:44:29 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Kinetis-Microcontrollers/CRC-module-K60-problems/m-p/242686#M6058</guid>
      <dc:creator>gigglerg</dc:creator>
      <dc:date>2013-03-27T16:44:29Z</dc:date>
    </item>
    <item>
      <title>Re: CRC module, K60 problems</title>
      <link>https://community.nxp.com/t5/Kinetis-Microcontrollers/CRC-module-K60-problems/m-p/242687#M6059</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Related to errata 2776?&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 27 Mar 2013 17:01:55 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Kinetis-Microcontrollers/CRC-module-K60-problems/m-p/242687#M6059</guid>
      <dc:creator>egoodii</dc:creator>
      <dc:date>2013-03-27T17:01:55Z</dc:date>
    </item>
    <item>
      <title>Re: CRC module, K60 problems</title>
      <link>https://community.nxp.com/t5/Kinetis-Microcontrollers/CRC-module-K60-problems/m-p/242688#M6060</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Yes that is correct, the problem is related to errata 2776 present in devices with the following mask sets:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;4N30D&lt;/LI&gt;&lt;LI&gt;8N30D&lt;/LI&gt;&lt;LI&gt;0M33Z&lt;/LI&gt;&lt;LI&gt;1N30D&lt;/LI&gt;&lt;LI&gt;2N30D&lt;/LI&gt;&lt;/UL&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 25 Apr 2013 16:04:21 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Kinetis-Microcontrollers/CRC-module-K60-problems/m-p/242688#M6060</guid>
      <dc:creator>apanecatl</dc:creator>
      <dc:date>2013-04-25T16:04:21Z</dc:date>
    </item>
  </channel>
</rss>

