<?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: malloc causes hardfault on RT1064 in i.MX Processors</title>
    <link>https://community.nxp.com/t5/i-MX-Processors/malloc-causes-hardfault-on-RT1064/m-p/1655963#M206382</link>
    <description>&lt;P&gt;Hi&amp;nbsp;&lt;a href="https://community.nxp.com/t5/user/viewprofilepage/user-id/188716"&gt;@Daan&lt;/a&gt;,&lt;/P&gt;
&lt;P&gt;First of all I must mention that the use of malloc in embedded systems is highly discouraged. As stated in &lt;A href="https://community.nxp.com/t5/i-MX-RT/default-malloc-behavior-in-MCUXpresso-SDK-example/m-p/1516108" target="_self"&gt;this post&lt;/A&gt;, malloc tries to allocate memory but does not check for operation overflow. This is why you are getting a BusFault (BFAR). Please follow the recommendations that are mentioned on the previous post I sent.&lt;/P&gt;
&lt;P&gt;BR,&lt;BR /&gt;Edwin.&lt;/P&gt;</description>
    <pubDate>Tue, 23 May 2023 18:47:07 GMT</pubDate>
    <dc:creator>EdwinHz</dc:creator>
    <dc:date>2023-05-23T18:47:07Z</dc:date>
    <item>
      <title>malloc causes hardfault on RT1064</title>
      <link>https://community.nxp.com/t5/i-MX-Processors/malloc-causes-hardfault-on-RT1064/m-p/1654581#M206256</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;Our project uses pretty much storage and RAM space, however, it compiles and runs perfectly. I notice that after the application runs for a while, maybe 10 minutes, maybe 1 hour, it just crashes, if I examine the stack trace, it always crashes inside the malloc function, I think that's strange, if malloc fails for some reason, it should return NULL, it should not cause a hardfault. I've setup a test program which will always fail after some time:&lt;/P&gt;&lt;LI-CODE lang="c"&gt;static void memtest(int16_t* state)
{
  volatile uint16_t siz = rand() &amp;amp; 0xfff; // Make sure the amount is not too much
  uint8_t* p = malloc(siz);
  static uint8_t n = 0;

  if (p == NULL)
  {
    VT100_printf(" Malloc fail!!!\r\n");
    *state = TASKSWAITSIGNAL;
  }
  else
  {
    free(p);
    if (n == 50)
    {
      VT100_printf(".");
      n = 0;
    }
    else n++;
  }
}&lt;/LI-CODE&gt;&lt;P&gt;This function is called periodically (500x/sec). It may run for an hour, or for 1 minute. The configured heap size is big enough, see the attached settings screenshot.&lt;/P&gt;&lt;P&gt;Furthermore, the application uses FreeRTOS with LWIP and the ethernet/MQTT stack.&lt;/P&gt;&lt;P&gt;Please also find attached a screenshot of the hardfault, an unaligned address allocation seems to cause the problem...&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;BR,&lt;/P&gt;&lt;P&gt;Daan&lt;/P&gt;</description>
      <pubDate>Mon, 22 May 2023 09:25:46 GMT</pubDate>
      <guid>https://community.nxp.com/t5/i-MX-Processors/malloc-causes-hardfault-on-RT1064/m-p/1654581#M206256</guid>
      <dc:creator>Daan</dc:creator>
      <dc:date>2023-05-22T09:25:46Z</dc:date>
    </item>
    <item>
      <title>Re: malloc causes hardfault on RT1064</title>
      <link>https://community.nxp.com/t5/i-MX-Processors/malloc-causes-hardfault-on-RT1064/m-p/1654623#M206260</link>
      <description>&lt;P&gt;I found this &lt;A href="https://community.nxp.com/t5/LPC-Microcontrollers/hardfault-cJSON-cJSON-CreateObject-while-LWIP-runs/m-p/1615117" target="_self"&gt;post&lt;/A&gt;&amp;nbsp;, we also use the cJSON library, so I thought I might face the same problem, but the hooks are still intact after the hardfault:&lt;/P&gt;&lt;P&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="Daan_0-1684746155872.png" style="width: 400px;"&gt;&lt;img src="https://community.nxp.com/t5/image/serverpage/image-id/224193i4D1BA5966CD06AD0/image-size/medium?v=v2&amp;amp;px=400" role="button" title="Daan_0-1684746155872.png" alt="Daan_0-1684746155872.png" /&gt;&lt;/span&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Mon, 22 May 2023 09:03:39 GMT</pubDate>
      <guid>https://community.nxp.com/t5/i-MX-Processors/malloc-causes-hardfault-on-RT1064/m-p/1654623#M206260</guid>
      <dc:creator>Daan</dc:creator>
      <dc:date>2023-05-22T09:03:39Z</dc:date>
    </item>
    <item>
      <title>Re: malloc causes hardfault on RT1064</title>
      <link>https://community.nxp.com/t5/i-MX-Processors/malloc-causes-hardfault-on-RT1064/m-p/1655737#M206370</link>
      <description>&lt;P&gt;According to &lt;A href="https://mcuoneclipse.com/2017/07/02/using-freertos-with-newlib-and-newlib-nano/" target="_self"&gt;this article&lt;/A&gt;&amp;nbsp;, a thread-safe version of malloc should be called when using multiple threads, so I modified my code to call pvPortMalloc(); initially this seemed to run stable, but unfortunately, the system crashed after 3 hours running at malloc again, since malloc is called by&amp;nbsp;pvPortMalloc.&lt;/P&gt;&lt;P&gt;The application is configured to use heap_3.c, which has a thread-safe implementation of malloc.&lt;/P&gt;</description>
      <pubDate>Tue, 23 May 2023 12:46:58 GMT</pubDate>
      <guid>https://community.nxp.com/t5/i-MX-Processors/malloc-causes-hardfault-on-RT1064/m-p/1655737#M206370</guid>
      <dc:creator>Daan</dc:creator>
      <dc:date>2023-05-23T12:46:58Z</dc:date>
    </item>
    <item>
      <title>Re: malloc causes hardfault on RT1064</title>
      <link>https://community.nxp.com/t5/i-MX-Processors/malloc-causes-hardfault-on-RT1064/m-p/1655963#M206382</link>
      <description>&lt;P&gt;Hi&amp;nbsp;&lt;a href="https://community.nxp.com/t5/user/viewprofilepage/user-id/188716"&gt;@Daan&lt;/a&gt;,&lt;/P&gt;
&lt;P&gt;First of all I must mention that the use of malloc in embedded systems is highly discouraged. As stated in &lt;A href="https://community.nxp.com/t5/i-MX-RT/default-malloc-behavior-in-MCUXpresso-SDK-example/m-p/1516108" target="_self"&gt;this post&lt;/A&gt;, malloc tries to allocate memory but does not check for operation overflow. This is why you are getting a BusFault (BFAR). Please follow the recommendations that are mentioned on the previous post I sent.&lt;/P&gt;
&lt;P&gt;BR,&lt;BR /&gt;Edwin.&lt;/P&gt;</description>
      <pubDate>Tue, 23 May 2023 18:47:07 GMT</pubDate>
      <guid>https://community.nxp.com/t5/i-MX-Processors/malloc-causes-hardfault-on-RT1064/m-p/1655963#M206382</guid>
      <dc:creator>EdwinHz</dc:creator>
      <dc:date>2023-05-23T18:47:07Z</dc:date>
    </item>
    <item>
      <title>Re: malloc causes hardfault on RT1064</title>
      <link>https://community.nxp.com/t5/i-MX-Processors/malloc-causes-hardfault-on-RT1064/m-p/1656352#M206424</link>
      <description>&lt;P&gt;Hi Edwin, thanks for your reply. As you can see in my code, I call malloc(), but immediately right after that, I free it again, so I don't think the memory reservation will run beyond the heap, since I also reserve just small pieces of memory. Furthermore, the NXP SDK also uses malloc, which in my opinion isn't such a bad idea, there is plenty of RAM available. I'll dive a little deeper and check the addresses malloc returns.&lt;/P&gt;</description>
      <pubDate>Wed, 24 May 2023 07:06:45 GMT</pubDate>
      <guid>https://community.nxp.com/t5/i-MX-Processors/malloc-causes-hardfault-on-RT1064/m-p/1656352#M206424</guid>
      <dc:creator>Daan</dc:creator>
      <dc:date>2023-05-24T07:06:45Z</dc:date>
    </item>
  </channel>
</rss>

