<?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 Re: CRC failed on 802.15.4 MAC/PHY ??? in 8-bit Microcontrollers</title>
    <link>https://community.nxp.com/t5/8-bit-Microcontrollers/CRC-failed-on-802-15-4-MAC-PHY/m-p/130664#M2539</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;But how could the packet get corrupted after the MAC sends it to the app using an MCPS_Data.indication? The MAC uses a memory pool from which it allocates its messages dynamically. Only my packet handling function should be accessing its memory until I free it, unless of course the memory management (Freescale code) has a problem???&lt;BR /&gt;&lt;BR /&gt;Thanks&lt;BR /&gt;Marc&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Fri, 31 Mar 2006 06:41:47 GMT</pubDate>
    <dc:creator>Marc</dc:creator>
    <dc:date>2006-03-31T06:41:47Z</dc:date>
    <item>
      <title>CRC failed on 802.15.4 MAC/PHY ???</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/CRC-failed-on-802-15-4-MAC-PHY/m-p/130662#M2537</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;SPAN&gt;Hi,&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;We've modified the EVK Switch demo to be sending direct data packets at full speed from a coordinator to an FFD device (RX on when idle). We only send one 102 byte packet at a time, waiting for a positive or negative acknoledgement before re-sending. This sends approximately 120 packets per second.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;We're sending dummy data but we've added our own little simple 8 bit checksum inside the data packet. At reception on the device, we verify the checksum and enter a dead loop if it fails.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;We've notice that the program will enter the dead loop after some varying amount of time (from 15 min, to a couple of hours). This would indicate that the received data was incorrect, but that the CRC of the MAC/PHY still accepted it.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Is this possible? Any ideas?&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Marc&lt;/SPAN&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 31 Mar 2006 04:24:05 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/CRC-failed-on-802-15-4-MAC-PHY/m-p/130662#M2537</guid>
      <dc:creator>Marc</dc:creator>
      <dc:date>2006-03-31T04:24:05Z</dc:date>
    </item>
    <item>
      <title>Re: CRC failed on 802.15.4 MAC/PHY ???</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/CRC-failed-on-802-15-4-MAC-PHY/m-p/130663#M2538</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;HI Marc:&lt;BR /&gt;&lt;BR /&gt;The first thing that occurs to me is that your packet gets corrupted in the middle of the process (after being received, but before finishing the checksum check).&lt;BR /&gt;&lt;BR /&gt;Maybe another interrupt is causing this, or a second packet overwriting the first packet, or a NULL packet?&lt;BR /&gt;&lt;BR /&gt;Regards,&lt;BR /&gt;&lt;BR /&gt;Alex&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 31 Mar 2006 06:20:54 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/CRC-failed-on-802-15-4-MAC-PHY/m-p/130663#M2538</guid>
      <dc:creator>alex_spotw</dc:creator>
      <dc:date>2006-03-31T06:20:54Z</dc:date>
    </item>
    <item>
      <title>Re: CRC failed on 802.15.4 MAC/PHY ???</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/CRC-failed-on-802-15-4-MAC-PHY/m-p/130664#M2539</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;But how could the packet get corrupted after the MAC sends it to the app using an MCPS_Data.indication? The MAC uses a memory pool from which it allocates its messages dynamically. Only my packet handling function should be accessing its memory until I free it, unless of course the memory management (Freescale code) has a problem???&lt;BR /&gt;&lt;BR /&gt;Thanks&lt;BR /&gt;Marc&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 31 Mar 2006 06:41:47 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/CRC-failed-on-802-15-4-MAC-PHY/m-p/130664#M2539</guid>
      <dc:creator>Marc</dc:creator>
      <dc:date>2006-03-31T06:41:47Z</dc:date>
    </item>
    <item>
      <title>Re: CRC failed on 802.15.4 MAC/PHY ???</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/CRC-failed-on-802-15-4-MAC-PHY/m-p/130665#M2540</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;HI:&lt;BR /&gt;&lt;BR /&gt;I haven't use the MAC code, but the SMAC that did have questionable programming techniques, like reeentrant interrupts for changing modes (from Idle to TX, to RX, etc).&lt;BR /&gt;&lt;BR /&gt;You might want to code review the MCS code to try to find memory leaks.&lt;BR /&gt;&lt;BR /&gt;Regards,&lt;BR /&gt;&lt;BR /&gt;Alex&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 31 Mar 2006 22:37:36 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/CRC-failed-on-802-15-4-MAC-PHY/m-p/130665#M2540</guid>
      <dc:creator>alex_spotw</dc:creator>
      <dc:date>2006-03-31T22:37:36Z</dc:date>
    </item>
    <item>
      <title>Re: CRC failed on 802.15.4 MAC/PHY ???</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/CRC-failed-on-802-15-4-MAC-PHY/m-p/130666#M2541</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;Do you have any suggestions as to what to look for?&lt;BR /&gt;&lt;BR /&gt;Thanks&lt;BR /&gt;Marc&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 05 Apr 2006 03:06:47 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/CRC-failed-on-802-15-4-MAC-PHY/m-p/130666#M2541</guid>
      <dc:creator>Marc</dc:creator>
      <dc:date>2006-04-05T03:06:47Z</dc:date>
    </item>
  </channel>
</rss>

