F4 + FreeRTOS + LwIP. Bad default LWIP_RAM_HEAP_POINTER after updating to v1.9.0.

[ASalc.1]

Hi,

After updating the IDE to v1.9.0 I experienced an error during memory allocation for LwIP. Now, settings make explicit the declaration of LWIP_RAM_HEAP_POINTER. By default it is 0x30044000 which is out of memory limits. I'm not totally sure about this, but if the pointer is changed to 0x20017f58 (the direction used by my project in the previous version of the IDE) it works.

It would be nice to have an option to use the automatic definition of the pointer. Code for this is still available in mem.c

#ifndef LWIP_RAM_HEAP_POINTER
/** the heap. we need one struct mem at the end and some room for alignment */
LWIP_DECLARE_MEMORY_ALIGNED(ram_heap, MEM_SIZE_ALIGNED + (2U * SIZEOF_STRUCT_MEM));
#define LWIP_RAM_HEAP_POINTER ram_heap
#endif /* LWIP_RAM_HEAP_POINTER */

 Using STM32479I-EVAL, FreeRTOS v2 + LwIP.

Edit: the solution I'm using is commenting

#define LWIP_RAM_HEAP_POINTER 0x30044000

in lwipopts.h.

[MHama.3]

Hello ASalc,

I did the same but I still cant ping my Board, have you any advice?

Thanks

[ASalc.1]

Finally I had no luck also. After commenting LWIP_RAM_HEAP_POINTER, the program falls into an assertion in vPortValidateInterruptPriority. I didn't manage to debug that.

Currently I'm developing my project based on the example: "LwIP_UDPTCP_Echo_Server_Netconn_RTOS". It is functional for the moment (DHCP + ping + echo server)...

[MHama.3]

thank you for your reply!

[Aziz BRIGUI]

Hello @ASalc.1​ ,

Thank you for your contribution,

You are right, this is a regression and has been reported. A workaround would be to copy the lines below in lwipopts.h under user section 1 (line 105). Then you will be able to do the ping test.

/* USER CODE BEGIN 1 */
#define CHECKSUM_GEN_ICMP 0
#define CHECKSUM_CHECK_ICMP 0
#undef LWIP_SUPPORT_CUSTOM_PBUF
#undef LWIP_RAM_HEAP_POINTER
/* USER CODE END 1 */

NOTE : You have to add this line under the main loop.

MX_LWIP_Process();

Internal ticket number: 125385 (This is an internal tracking number and is not accessible or usable by customers).

If your issue is solved, please close this post by clicking the "Select as Best" button. This will help other members of the community find this response more quickly.

Best regards,

Aziz

[ASalc.1]

Hello @Aziz BRIGUI​ , thanks for your reply.

After adding those lines, once the first packet is sent (DHCP discover), it falls into the infinite loop of the next assertion (port.c , line 770):

configASSERT( ( portAIRCR_REG & portPRIORITY_GROUP_MASK ) <= ulMaxPRIGROUPValue );

Looking at the trace, it seems that the problem is with the priority group having subpriority bits in the ETH interruption. The NVIC is supposed to be properly configured with 4 preemption bits and 0 for subpriority. The value of portAIRCR_REG is 0xfa050300 when it should be 0xfa050000...

[Tesla DeLorean]

Related, cross-referencing to find later

https://community.st.com/s/question/0D53W00001ScqS1SAJ/lwip-get-hardfaulthandler-after-update-on-stm32cubeide-v190

[Aziz BRIGUI]

Hello @ASalc.1​ ,

Could you please share your ioc file so that we can reproduce the issue ?

Best regards,

Aziz

[ASalc.1]

Yes!