# FreeRTOS Plus TCP example Project going into HardFault **URL:** \ **Category:** Libraries\ **Tags:** debug\ **Created:** [February 22, 2024, 3:55am UTC](https://forums.freertos.org/t/freertos-plus-tcp-example-project-going-into-hardfault/19234 "2024-02-22T03:55:58Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![nop](https://avatars.discourse-cdn.com/v4/letter/n/48db29/32.png) [@nop](https://forums.freertos.org/u/nop)\ **Post date:** [February 22, 2024, 3:55am UTC](https://forums.freertos.org/t/freertos-plus-tcp-example-project-going-into-hardfault/19234/1 "2024-02-22T03:55:58Z")
Hi everyone, i was able to compile and run this (unoffical) example Project for the STM32F4: [freertos\_plus\_projects/plus/stm32F40 at master · htibosch/freertos\_plus\_projects · GitHub](https://github.com/htibosch/freertos_plus_projects/tree/master/plus/stm32F40) Some adjustments were necessary, thanks [htibosch](https://forums.freertos.org/u/htibosch) for the help! At first sight everything seemed fine, ping works, telnet console works, unplug and replug, … but if i put it under some load, ether by running an iperf test or doing a portscan the cpu gets stuck in HardFault. What could be the Problem? Could it be related to stack sizes or some buffer size being configured wrong? the PC value getting saved before the HardFault loop points to this line (which is one line after a memcpy) ```auto (gdb) l *pc 0x800e620 is in vIPerfTask (PWD/freertos_plus_projects/plus/Common/Utilities/iperf_task_v3_0g.c:503). 503 pxDataClient->ullAmount = pxControlClient->ullAmount; ``` and if i do a portscan with nmap it gets stuck pointing to this line: ```auto (gdb) l *pc 0x801876c is in prvTCPReturnPacket_IPV4 (PWD/freertos_plus_projects/plus/Framework/FreeRTOS-Plus-TCP-main/source/FreeRTOS_TCP_Transmission_IPv4.c:147). 147 pxIPHeader = ( ( IPHeader_t * ) &( pxNetworkBuffer->pucEthernetBuffer[ipSIZE_OF_ETH_HEADER] ) ); ``` I was looking forward to using this as a reference for my Project, so it would be great to understand this issue and ultimately get rid of it. ---
**Author:** ![kstribrn](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/kstribrn/32/2085_2.png) [@kstribrn](https://forums.freertos.org/u/kstribrn)\ **Post date:** [February 23, 2024, 10:27pm UTC](https://forums.freertos.org/t/freertos-plus-tcp-example-project-going-into-hardfault/19234/2 "2024-02-23T22:27:14Z")
> [@nop](#): > > What could be the Problem? Could it be related to stack sizes or some buffer size being configured wrong? This seems like a solid assumption. How large is your [network descriptor ethernet buffer](https://github.com/FreeRTOS/FreeRTOS-Plus-TCP/blob/ef14a0871f6ed21c83a97eb176583b5a0cec67e7/source/include/FreeRTOS_IP.h#L163)? How many [network buffers do you have configured](https://www.freertos.org/FreeRTOS-Plus/FreeRTOS_Plus_TCP/TCP_IP_Configuration.html#ipconfigNUM_NETWORK_BUFFER_DESCRIPTORS)? And what is the [size of your task stack](https://www.freertos.org/a00125.html)? ---
**Author:** ![aggarg](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/aggarg/32/4245_2.png) [@aggarg](https://forums.freertos.org/u/aggarg)\ **Post date:** [February 26, 2024, 7:03am UTC](https://forums.freertos.org/t/freertos-plus-tcp-example-project-going-into-hardfault/19234/3 "2024-02-26T07:03:51Z")
> [@nop](#): > > ```auto > (gdb) l *pc > 0x800e620 is in vIPerfTask (PWD/freertos_plus_projects/plus/Common/Utilities/iperf_task_v3_0g.c:503). > 503 pxDataClient->ullAmount = pxControlClient->ullAmount; > > ``` Can you examine `pxDataClient` and `pxControlClient` and see if those seem corrupted? Also, see `dst` of `memcpy` and see if there is a possibility of buffer overrun or stack overflow. ---
**Author:** ![nop](https://avatars.discourse-cdn.com/v4/letter/n/48db29/32.png) [@nop](https://forums.freertos.org/u/nop)\ **Post date:** [March 16, 2024, 5:32am UTC](https://forums.freertos.org/t/freertos-plus-tcp-example-project-going-into-hardfault/19234/4 "2024-03-16T05:32:28Z")
Hi again, thanks for the replies. After looking into this problem a few times (and then getting distracted), i finally looked at the disassembly and now the solution was quite simple. ```auto 114│ 147 pxIPHeader = ( ( IPHeader_t * ) &( pxNetworkBuffer->pucEthernetBuffer[ipSIZE_OF_ETH_HEADER] ) ); 115│ 0x0801862a <+58>: ldr r3, [r4, #36] @ 0x24 116├──> 0x0801862c <+60>: udf #255 @ 0xff ``` The problem was gcc generating an udf opcode, this can be disabled with `-fno-delete-null-pointer-checks`. see [this st forum post](https://community.st.com/t5/stm32-mcus-products/memory-protection-around-location-0/td-p/423353). I don’t really understand the underlying mechanics of this problem and why `hping --fast` makes it not reach this code but `hping --faster` does, but this solved it. The other chrash was a similar problem: ```auto 903│ 503 pxDataClient->ullAmount = pxControlClient->ullAmount; 904│ 0x0800e4d8 <+988>: ldr.w r3, [r10] 905│ 0x0800e4dc <+992>: ldr.w r0, [r9] 906├──> 0x0800e4e0 <+996>: vldr d16, [r3, #16] ``` with vldr d16 the compiler tried to use a non existing fpu core register (should only have d0-d15). And indeed the makefile specified the wrong fpu type: ```auto - -mfpu=vfpv4 \ + -mfpu=fpv4-sp-d16 \ ``` i hope i will get to upload and share a cleaned up version of the example-project at some point when i got time… ---
**Author:** ![RAc](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rac/32/1389_2.png) [@RAc](https://forums.freertos.org/u/RAc)\ **Post date:** [March 16, 2024, 6:36am UTC](https://forums.freertos.org/t/freertos-plus-tcp-example-project-going-into-hardfault/19234/5 "2024-03-16T06:36:06Z")
> [@nop](#): > > The problem was gcc generating an udf opcode, this can be disabled with `-fno-delete-null-pointer-checks`. see [this st forum post](https://community.st.com/t5/stm32-mcus-products/memory-protection-around-location-0/td-p/423353). > I don’t really understand the underlying mechanics of this problem and why `hping --fast` makes it not reach this code but `hping --faster` does, but this solved it. To me this reads as if the compiler inserts code to trap NULL pointer dereferencing, meaning that > pxNetworkBuffer-\>pucEthernetBuffer is 0 at the point of execution. Is that a valid address on your platform? If not, you may just be curing the symptoms, but not the cause. ---
**Author:** ![nop](https://avatars.discourse-cdn.com/v4/letter/n/48db29/32.png) [@nop](https://forums.freertos.org/u/nop)\ **Post date:** [March 17, 2024, 3:30pm UTC](https://forums.freertos.org/t/freertos-plus-tcp-example-project-going-into-hardfault/19234/6 "2024-03-17T15:30:35Z")
I suspect some things get written by the DMA, so the compiler is not aware of it. If it really still is a nullpointer at execution time, shouldn’t the cpu also go into a fault handler? the code seems to run stable now, but i get what you mean with treating symptoms… ---
**Author:** ![RAc](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rac/32/1389_2.png) [@RAc](https://forums.freertos.org/u/RAc)\ **Post date:** [March 17, 2024, 4:19pm UTC](https://forums.freertos.org/t/freertos-plus-tcp-example-project-going-into-hardfault/19234/7 "2024-03-17T16:19:27Z")
> [@nop](#): > > If it really still is a nullpointer at execution time, shouldn’t the cpu also go into a fault handler? Not necessarily. On many MCUs, 0 is mapped to the beginning of internal flash which is always readable (and may also be writeable when in flash programming mode), so 0 pointer dereferencing by itself is neither illegal nor technically forbidden in such scenarios. Yet it is one very very common cause for runtime problems, so I suspect that this compiler setting is an optional aid for developers to trap this case and distinguish it from more generic access errors even in those cases where there is no memory mapped to 0. Again, without this setting in action, it may be the case that your code still attempts to access network buffers at address 0, but coincidentally, the memory behind it (the IVT probably) causes the network driver to bail out in a begnine manner. According to Murphy, this WILL at some point (eg after a firmware update that leaves the IVT different) make the software fail, and most probably at the most critical and inaccessible site of your most important customer. BTDT. I would leave the check in, wait till it gets hit and then inspect your data structures. Alternatively, you could set a hardware breakpoint to catch null pointer dereferences.