Skip to main content
Visitor II
October 11, 2024
Solved

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

  • October 11, 2024
  • 3 replies
  • 1137 views

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

 

 

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

    Hello STea,

    Took us some time to solve the issue, but it turned out that our VCAP1 and VCAP2 capacitors for the regulator stabilization were installed incorrectly at a value of 2.2 nF. When we replaced the capacitors with the proper value of 2.2 uF, all our issues were resolved.

    3 replies

    ST Employee
    October 15, 2024

    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

    ae_btiAuthor
    Visitor II
    October 15, 2024

    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

    ST Employee
    October 24, 2024

    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

    ST Employee
    December 30, 2024

    Hello @ae_bti ,

    any updates?
    Regards

    ae_btiAuthorAnswer
    Visitor II
    January 6, 2025

    Hello STea,

    Took us some time to solve the issue, but it turned out that our VCAP1 and VCAP2 capacitors for the regulator stabilization were installed incorrectly at a value of 2.2 nF. When we replaced the capacitors with the proper value of 2.2 uF, all our issues were resolved.