# Hardfault observed in BufferAllocation under FREERTOS IP Stack **URL:** \ **Category:** Kernel\ **Created:** [May 24, 2019, 3:34am UTC](https://forums.freertos.org/t/hardfault-observed-in-bufferallocation-under-freertos-ip-stack/7872 "2019-05-24T03:34:23Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![ingamow](https://avatars.discourse-cdn.com/v4/letter/i/c77e96/32.png) [@ingamow](https://forums.freertos.org/u/ingamow)\ **Post date:** [May 24, 2019, 3:34am UTC](https://forums.freertos.org/t/hardfault-observed-in-bufferallocation-under-freertos-ip-stack/7872/1 "2019-05-24T03:34:23Z")
**[ingamow](https://sourceforge.net/u/ingamow/)** wrote on [Friday, May 24, 2019](https://sourceforge.net/p/freertos/discussion/382005/thread/a93c19999d/#0d94): Hi, I’ve currently updated the FreeRTOS version from v8.2.1 to v10.2.0 on my Cortex-M0 based project. Along with that, the existent LWIP stack was replaced by FreeRTOS IP Stack. Everything worked fine. But Stability tests revealed a critical bug. It was a Hardfault. (A configAssert call probably) I went on to debug that, the link register pointed to the below section in BufferAllocation2.c (We are using this and heap4.c) _**FreeRTOS-Plus-TCP/portable/BufferManagement/BufferAllocation2.c:229 } \*\* \*\* / If there is a semaphore available, there is a network buffer available. / \*\* if( xSemaphoreTake( xNetworkBufferSemaphore, xBlockTimeTicks ) == pdPASS ) 917c2: 4b1d ldr r3, [pc, #116] ; (91838 \) 917c4: 6818 ldr r0, [r3, #0] 917c6: f7fa f924 bl 8ba12 917ca: 2801 cmp r0, #1 917cc: d130 bne.n 91830 \_\*\* THIS WAS THE LINE LINK REGISTER POINTED TO. As I am a newbie to FreeRTOS, I’ve literally no idea how this happens, Please Help. ---
**Author:** ![htibosch](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/htibosch/32/62_2.png) [@htibosch](https://forums.freertos.org/u/htibosch)\ **Post date:** [May 24, 2019, 4:11am UTC](https://forums.freertos.org/t/hardfault-observed-in-bufferallocation-under-freertos-ip-stack/7872/2 "2019-05-24T04:11:10Z")
**[heinbali01](https://sourceforge.net/u/heinbali01/)** wrote on [Friday, May 24, 2019](https://sourceforge.net/p/freertos/discussion/382005/thread/a93c19999d/#63cd): Hi, > It was a Hardfault. (A configAssert call probably) Was it is a hard-fault or a `configAssert()`? The latter is easier to solve. The former will end-up in `HardFault_Handler()`. Both end in a for-ever-loop. Do you have`configAssert()` properly defined? Often in NetworkInterface.c, you will see calls to `uxGetNumberOfFreeNetworkBuffers()` and `uxGetMinimumFreeNetworkBuffers()`. It produces logging when the levels get low. Do you have that logging enabled? And while you are testing, it is also good to keep an aye on the available heap memory. Both heap\_4 and heap\_5 are very good. I like heap\_5 because you can determine dynamically how much RAM is actually available. Can you confirm that `xNetworkBufferSemaphore` is created and valid? You are not allocating a Network Buffer or using the +TCP API’s before `FreeRTOS_IPInit()` has successfully finished? In more general terms: problems with Network Buffers are usually caused by: - Forgetting to release buffers - Releasing a buffer more than one time - Accessing more memory in `pucEthernetBuffer` than allocated The free network buffers are stored in a `List_t`, which is guarded by a counting semaphore. Updates to `List_t` need critical sections. ---
**Author:** ![ingamow](https://avatars.discourse-cdn.com/v4/letter/i/c77e96/32.png) [@ingamow](https://forums.freertos.org/u/ingamow)\ **Post date:** [May 24, 2019, 10:23am UTC](https://forums.freertos.org/t/hardfault-observed-in-bufferallocation-under-freertos-ip-stack/7872/3 "2019-05-24T10:23:09Z")
**[ingamow](https://sourceforge.net/u/ingamow/)** wrote on [Friday, May 24, 2019](https://sourceforge.net/p/freertos/discussion/382005/thread/a93c19999d/#02be): Hi, > You are not allocating a Network Buffer or using the +TCP API’s before FreeRTOS\_IPInit() has successfully finished? It seemed, the buffer allocation was happening even before a call to FreeRTOS\_IPInit(). Fixing this, sort of solved the issue. Need to do more stability tests to confirm it. Anyway thanks so much for your feedback Mr. Hein Tibosch ---
**Author:** ![htibosch](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/htibosch/32/62_2.png) [@htibosch](https://forums.freertos.org/u/htibosch)\ **Post date:** [May 25, 2019, 5:02am UTC](https://forums.freertos.org/t/hardfault-observed-in-bufferallocation-under-freertos-ip-stack/7872/4 "2019-05-25T05:02:19Z")
**[heinbali01](https://sourceforge.net/u/heinbali01/)** wrote on [Saturday, May 25, 2019](https://sourceforge.net/p/freertos/discussion/382005/thread/a93c19999d/#2018): Glad you’ve found where the problem is, and thanks for taking the effort to report back. It looks like you don’t have `configASSERT()` enabled. `xQueueSemaphoreTake()` is called while `pxQueue` is NULL. But also with `configASSERT()` enabled, your program would get stuck. `BufferAllocation_1.c` does check if `xNetworkBufferSemaphore` has been created, and I will propose to make the same check in `BufferAllocation_2.c`. See my pull request [here](https://github.com/aws/amazon-freertos/pull/674)