cancel
Showing results for 
Search instead for 
Did you mean: 

freeRTOS + LwIP crashing on STM32F746VGT6, but not on STM32F746G-DISCO

ae_bti
Associate

Hello,

I am using an STM32F746VGT6 with a LAN8742A PHY to implement a basic TCP server using freeRTOS + LwIP for text communications. I've attached the code below:

 

 

#include "bti_tcpecho.h"

#define TCP_SERVER_TASK_PRIORITY 10

BaseType_t bti_tcp_server_return;
TaskHandle_t tcp_server_task_handle;

static void tcpecho_thread(void *arg){

	struct netconn *conn, *newconn;
	err_t err;
	err_t accept_err;
	err_t recv_err;
	LWIP_UNUSED_ARG(arg);

	////
	char echo_msg[4] = "echo";
	u16_t echo_len = 4;

	conn = netconn_new(NETCONN_TCP);

	if(conn != NULL){
		err = netconn_bind(conn, NULL, 7);
	}

	if(err == ERR_OK){
		netconn_listen(conn);

		while(1){
			accept_err = netconn_accept(conn, &newconn); 

			if(accept_err == ERR_OK){
				struct netbuf *buf;
				void *data;
				u16_t len;

				while((recv_err = netconn_recv(newconn, &buf)) == ERR_OK){ 
					do{
						netbuf_data(buf, &data, &len); 
						netconn_write(newconn, data, len, NETCONN_COPY); 

						netconn_write(newconn, echo_msg, echo_len, NETCONN_COPY);
					}
					while(netbuf_next(buf) >= 0); 

					netbuf_delete(buf);
				}
				netconn_close(newconn);
				netconn_delete(newconn);
			}
		}
	}
	else{
		netconn_delete(newconn);
	}
}

void tcpecho_init(void){
	sys_thread_new("tcpecho_thread", tcpecho_thread, NULL, DEFAULT_THREAD_STACKSIZE, TCP_SERVER_TASK_PRIORITY);
}

 

 

This seems to run fine on my board, until I changed lines 17 and 18 to some string longer than "echo". For example, the following code will cause the MCU to hard fault right away on startup (even before any client tries to connect): 

char echo_msg[8] = "echo1234";

u16_t echo_len = 8;

The program seems to crash at some memset() in startup. Here are two examples of the crashes:

 

ae_bti_0-1728673788383.pngae_bti_1-1728673816716.png

 

ae_bti_2-1728673957449.pngae_bti_3-1728673971887.png

 

Here is the defaultTask:

 

void StartDefaultTask(void const * argument)

{

/* init code for LWIP */

MX_LWIP_Init();

/* USER CODE BEGIN 5 */

 

tcpecho_init();

 

/* Infinite loop */

for(;;)

{

osDelay(1);

}

/* USER CODE END 5 */

}

 

I tried flashing this exact same code onto a STM32F746G-DISCO, and it works perfectly, regardless of the string contained in echo_msg. The MPU configuration is the same for both:

 

ae_bti_4-1728674538000.png

 

All the settings for freeRTOS and LwIP are set to default, except for the defaultTask stack size, which I set to 512 words.

 

Here is the partial board schematic:

 

ae_bti_5-1728674865009.png

 

 

3 REPLIES 3
STea
ST Employee

Hello @ae_bti ,

when you use the same code with a disco board you don't get into such issues as i understand could you confirm this.

also, could you check the placement of the ethernet descriptors and Lwip heap and the way you are allocating stack for your FreeRtos tasks? 
Regards

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Hello STea,

Thank you for your response. Yes, when I flash the same code onto the STM32F746G-DISCO board, I don't get any hard faults. I have checked the placement of the ethernet descriptors, the LwIP heap, and the freeRTOS task stacks. They are all the exact same for both boards. I've attached the associated configurations below.

ae_bti_0-1728998566550.png

ae_bti_1-1728998596762.png

ae_bti_2-1728999546340.png

ae_bti_3-1728999570076.png

ae_bti_4-1728999611334.png

ae_bti_5-1728999626682.png

STea
ST Employee

Hello @ae_bti ,

if the Firmware is working on the Disco board and not on your custom board clearly this is a Hardware issue. here are some things to look for 
make sure you have the same part number for your board.

make sure also that the .ld file places the descriptors in the same region as the Discovery board and that the memory region definitions are the same.

you said that it worked with small amount of Data so misconfiguration or soldering issue with the PHY is out of the table 
I hope you find a solution to this soon and don't hesitate to update us on this issue as this is very unorthodox to see.
Regards

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.