cancel
Showing results for 
Search instead for 
Did you mean: 

Issue in FW F7 HAL package 1.17.x

Petr3
Associate III

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

1 ACCEPTED SOLUTION

Accepted Solutions
CMYL
ST Employee

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, 

View solution in original post

11 REPLIES 11
CMYL
ST Employee

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,

CMYL
ST Employee

Hello again @Petr3,

Can you share the Mx project ?

 

best regards

Petr3
Associate III

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.

Petr3
Associate III

Hello @CMYL , here is the project.

CMYL
ST Employee

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 

CMYL
ST Employee

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, 

CMYL
ST Employee

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
Principal

@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.

CMYL
ST Employee

@Bob S, I agree thank you 🙂

8 * 128 --> 4 * 256