Skip to main content
Associate III
December 11, 2023
Solved

Issue in FW F7 HAL package 1.17.x

  • December 11, 2023
  • 8 replies
  • 3371 views

Hi,

i have STM32F767BIT6 MCU and microcontroller crashes into Hard Fault during initialisation of LWIP MX_LWIP_Init(); Problem is that in FreeRTOS is calling memcpy in queue.c in function prvCopyDataFromQueue with huge ammount of length.

( void ) memcpy( ( void * ) pvBuffer, ( void * ) pxQueue->u.xQueue.pcReadFrom, ( size_t ) pxQueue->uxItemSize );

Source(pxQueue->u.xQueue.pcReadFrom) and destination(pvBuffer) address is correct placed inside internal SRAM area but length(pxQueue->uxItemSize) is so huge, that end address is placed out of accessible area. So it goes into HardFault_Handler.

 

When i created the same project in older STM32cubeIDE 1.6 (FW F7 package 1.16.x) it works fine but when i create project with newer STM32cubeIDE (1.10 or 1.12 or 1.14) with FW F7 package 1.17.x it crashes into HardFault_Handler.

 

Best regards,

Petr

This topic has been closed for replies.
Best answer by CMYL

Hello @Petr3,

I increased the size of the stack for defaultTask calling LWIP init (MX_LWIP_Init();) and it is working now.

.stack_size = 128 * 8,     // .stack_size = 128 * 4, 

Please find attached the project without ~/drivers, ~/LWIP and ~/Middelwares that can be copied from another project. Note that I'm using the STM32F756ZG, you can clone it to STM32F767 and try it. 

I confirm the issue has no relation with GCC version.

Let me know if you face any other issues. 

Best regards, 

8 replies

Technical Moderator
December 11, 2023

Hello @Petr3,

The GCC version changed from older STM32CubeIDE v1.6 to newer ones.

memcpy and memset are part of libc_nano.a, v5.4.1 in older STM32cubeIDE_1.6 and version v6.2.1 newer STM32cubeIDE_1.10 ...

I will try to reproduce the issue in order to escalate it to the STM32CubeIDE development team, on my side.

Can you stay with older version until checking the issue? or as a workaround, can you copy the older libc_nano.a to ‘tools\compiler\arm-none-eabi\lib\thumb\v6-m\libc_nano.a and disable all optimizations ?

 

Best regards,

Petr3Author
Associate III
December 11, 2023

Hello @CMYL ,

yes, i can try it. But im not sure that problem is in new GCC. Maybe in the ETH driver, i saw some ETH fixes/updates in driver for H7 with address where AXIM address 0x2400 0000 should be used.

My test project is following:

FreeRTOS + LWIP + GPIOI.6 as output. RCC is set as HSE 25MHz to the PLL 216MHz. LED on GPIOI.6 should flash in 500ms period in default task generated for init of LWIP, TIM1 is selected for base clock.

void StartDefaultTask(void *argument)

{

/* init code for LWIP */

MX_LWIP_Init();

/* USER CODE BEGIN 5 */

/* Infinite loop */

for(;;)

{

osDelay(500);

HAL_GPIO_WritePin(GPIOI, GPIO_PIN_6, GPIO_PIN_SET);

osDelay(500);

HAL_GPIO_WritePin(GPIOI, GPIO_PIN_6, GPIO_PIN_RESET);

}

/* USER CODE END 5 */

}

 

when i comment out MX_LWIP_Init(); LED start flashing as expected.

Technical Moderator
December 11, 2023

Hello again @Petr3,

Can you share the Mx project ?

 

best regards

Petr3Author
Associate III
December 11, 2023

Hello @CMYL , here is the project.

Technical Moderator
December 12, 2023

Hello @Petr3,

Thank you this is helpful, I reproduced the issue.

I'm actively working on this issue to find the root-cause

 

BR,

Younes 

CMYLBest answer
Technical Moderator
December 12, 2023

Hello @Petr3,

I increased the size of the stack for defaultTask calling LWIP init (MX_LWIP_Init();) and it is working now.

.stack_size = 128 * 8,     // .stack_size = 128 * 4, 

Please find attached the project without ~/drivers, ~/LWIP and ~/Middelwares that can be copied from another project. Note that I'm using the STM32F756ZG, you can clone it to STM32F767 and try it. 

I confirm the issue has no relation with GCC version.

Let me know if you face any other issues. 

Best regards, 

Petr3Author
Associate III
December 12, 2023

I agree, the stack extension helps and it works with it.

Thank you for help.

Technical Moderator
December 12, 2023

Hello @Petr3 

 

Internal ticket number: 168589 (This is an internal tracking number and is not accessible or usable by customers)", is submitted to increase the stack size of the FreeRTOS default task that initiates the WLIP, from 4* 128 to 8*128 in STM32CubeMx.

 

Best regards,

Younes

Bob S
Super User
December 12, 2023

@CMYLStaying with the usual way of specifying stack sizes that should be "4 * 256", where the first number (4) just converts a "dword" count into a "byte" count as expecteed in the osThreadAttr_t::stack_size variable.

Technical Moderator
December 12, 2023

@Bob S, I agree thank you :)

8 * 128 --> 4 * 256 

Technical Moderator
December 13, 2023

Good news, You are welcome :)