cancel
Showing results for 
Search instead for 
Did you mean: 

HTTP request to STM32 + LwIP results that Ping stops working

DMårt
Lead

Hello!

Recently I had problems with ping to my STM32 + LwIP + DP83848 + RMII. But the latest FW version 1.27.1, it works very well! But now I have problems with HTTP. Follow me and I show you how to create this bug.

First of all I'm using:

  • STM32CubeIDE 1.10.1
  • STM32F407VGT
  • FW 1.27.1

To reproduce this bug, do the following steps.

  • Step 1: Enable RMII by going to ETH -> RMII (Rx Buffer length 1524, MAC address 00:80:E1:00:00:00, Rx Mode = Interrupt, NVIC settings = Ethernet Global Interrupt)
  • Step 2: Go to FREERTOS and enable CMSIS V2 and go to Task & Queues. Change the Stack Size (Words) in defaultTask from 128 to 1024.
  • Step 3: Inside CMSIS V2, go to Advanced settings and set USE_NEWLIB_REENTRANT = Enabled. Leave everything else as default.
  • Step 4: Go to LWIP and enable it. Set LWIP_DHCP = disabled in General Settings and then write in the fixed IP address. In my case it is 192.168.1.35.
  • Step 5: Inside LWIP, go to HTTPD and set LWIP_HTTPD = enabled. Inside LWIP go to Key Options and set MEM_SIZE = 10*1024. Leave everything else as default.
  • Step 6: Download the FSDATA.zip folder and extract it.
  • Step 7: The FSDATA.zip folder contains a folder called FS and makeFSdata.exe. The makeFSdata.exe file will create a file called fsdata.c. Click on that.
  • Step 8: When the makeFSdata.exe file have created fsdata.c then rename fsdata.c to fsdata_custom.c.
  • Step 9: Place fsdata_custom.c at \Middlewares\Third_Party\LwIP\src\apps
  • Step 10: Right click fsdata_custom.c -> Resource Configurations -> Extract From Build ... -> Select All -> OK.
  • Step 11: Compile the project to your STM32 board and then ping.

0693W00000QN3y9QAD.png 

OK! It Working great!

  • Step 12: Download HTTP_Server.zip and extract it into the projects src folder.
  • Step 13: Write this into your main.c file
#include "HTTP_Server/httpserver.h"
  • Step 14: Add http_server_init(); to
/* USER CODE BEGIN Header_StartDefaultTask */
/**
  * @brief  Function implementing the defaultTask thread.
  * @param  argument: Not used
  * @retval None
  */
/* USER CODE END Header_StartDefaultTask */
void StartDefaultTask(void *argument)
{
  /* init code for LWIP */
  MX_LWIP_Init();
  /* USER CODE BEGIN 5 */
  http_server_init();
  /* Infinite loop */
  for(;;)
  {
    osDelay(1);
  }
  /* USER CODE END 5 */
}
  • Step 15: Compile and go to your web browser and type in 192.168.1.35/index.html. No web site is displayed. Also if I ping now, then I get no response....BUT....if I restart the processor, then ping, the ping is working. But as long I don't go to the 192.168.1.35/index.html website, my STM32 processor have connection to the DHCP server and I can ping it.

Question:

Why does this happen?

I have followed this tutorial 100% (except that he are using another processor) https://www.youtube.com/watch?v=haO8_eLIDeI&ab_channel=ControllersTech

This must be a bug, becase in FW 1.27.0 version, I had problems with ping my processor. In FW 1.27.1, the ping works like a charm. But now FW 1.27.1 resulting that my HTTPD won't work.

Thank you.

STM32MP151AAC3 custom board with STM32-OS as operating system: https://github.com/DanielMartensson/STM32-Computer
46 REPLIES 46

With the "lwIP driver" I mean the code in ethernetif.c file.

Dear Mahdy,

When the most suitable solution will be available ? I suppose it was supposed to be fixed in June, isn't it ?

Regards,
Parvez Akhtar

Parvez Akhtar
Associate II

May I have the courtesy to get response from any STM Engineer ?

"When the most suitable solution will be available ? I suppose it was supposed to be fixed in June, isn't it ?"

 

Week 24 of 2023 is gone long ago. Did you get any fix yet ?

If you ask me - my project uses other kind of protocol, not tcp or http. We have not fixed all known bugs of the current driver but found a mode when it works "good enough". Also we have a different PHY.

IMHO high performance tcp or http requires extensive validation of the lower layer (raw L2). But skills and equipment for basic ethernet testing (Chariot test suite and so on) are now hard to find.

Using STM32Cube FW_F4 V1.28.0 on a custom STM32F417VGTx

Instead of replacing the const in your web pages, that will then finish residing in SRAM all the time and erroring with section `.bss' will not fit in region `RAM'

 

The problem is in httpd.c by trying to send directly from ROM, instead of copying to SRAM.

BUT, as the ETH Peripheral on the F407 and friends cannot access FLASH so the data must be copied to SRAM.

HTTP_IS_DATA_VOLATILE is defined by LWIP_HTTP_DYNAMIC_FILE_READ.

If LWIP_HTTP_DYNAMIC_FILE_READ is undefined then HTTP_IS_DATA_VOLATILE will be 0.

 

#if LWIP_HTTPD_DYNAMIC_FILE_READ
#define HTTP_IS_DYNAMIC_FILE(hs) ((hs)->buf != NULL)
#else
#define HTTP_IS_DYNAMIC_FILE(hs) 0
#endif

/* This defines checks whether tcp_write has to copy data or not */

#ifndef HTTP_IS_DATA_VOLATILE
/** tcp_write does not have to copy data when sent from rom-file-system directly */
#define HTTP_IS_DATA_VOLATILE(hs)       (HTTP_IS_DYNAMIC_FILE(hs) ? TCP_WRITE_FLAG_COPY : 0)
#endif

 

 

To ensure HTTP_IS_DATA_VOLATILE is set to TCP_WRITE_FLAG_COPY I defined HTTP_IS_DATA_VOLATILE in lwipopts.h. I also set HTTP_IS_HDR_VOLATILE to TCP_WRITE_COPY

 

/* This defines checks whether tcp_write has to copy data or not
 * Since CubeMX 1.27.1. always treat HTTP DATA as volatile, due to Zero copy ETH rewrite as STM32F40x and STM32F41x ETH cannot access FLASH
 */
#define HTTP_IS_DATA_VOLATILE(hs) TCP_WRITE_FLAG_COPY

/** Default: dynamic headers are sent from ROM (non-dynamic headers are handled like file data)
 * Since CubeMX 1.27.1. always treat HTTP HDR as volatile, due to Zero copy ETH rewrite as STM32F40x and STM32F41x ETH cannot access FLASH
 */
#define HTTP_IS_HDR_VOLATILE(hs, ptr) TCP_WRITE_FLAG_COPY

 

 

Now each call to http_write Will do a copy to SRAM, maybe wasteful, but I can't wait till next release.

err = http_write(pcb, hs->file, &len, HTTP_IS_DATA_VOLATILE(hs));

 

AH_TR
ST Employee

Hello,

Apologies for the delay,
For standalone projects, defining HTTP_IS_DATA_VOLATILE(hs) as TCP_WRITE_FLAG_COPY in lwipopts.h is the proper fix for data to be copied from flash memory.
No need to define HTTP_IS_HDR_VOLATILE(hs, ptr) as TCP_WRITE_FLAG_COPY if the header is included with the data as HTTP_IS_DATA_VOLATILE(hs) will copy the entire file content.
As for projects with RTOS using Netconn APIs, the flag NETCONN_COPY must be used in the netconn_write API.

These fixes will be implemented in the next upcoming cubeF4 maintenance release.

Kind regards