2022-08-05 04:13 AM
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:
To reproduce this bug, do the following steps.
OK! It Working great!
#include "HTTP_Server/httpserver.h"
/* 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 */
}
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.
2023-05-05 07:10 PM
With the "lwIP driver" I mean the code in ethernetif.c file.
2023-06-19 11:11 PM
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
2023-06-21 06:44 AM
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 ?"
2023-11-02 11:51 PM
Week 24 of 2023 is gone long ago. Did you get any fix yet ?
2023-11-03 04:18 AM
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.
2024-02-26 06:42 PM - edited 2024-02-27 01:58 AM
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));
2024-03-11 04:16 AM
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