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-01-03 11:38 AM
Yes. Now it's working.
I tried both with FreeRTOS and without FreeRTOS. With FreeRTOS, the connection was slow, or sometimes my webbserver did not responds. It was due to threads doing something else. Sometimes it works, sometimes not.
But without FreeRTOS. I just only need to write this code in main.c file
/* HTTP Deamon */
httpd_init();
/* USER CODE END 2 */
/* Infinite loop */
/* USER CODE BEGIN WHILE */
while (1)
{
/* USER CODE END WHILE */
/* USER CODE BEGIN 3 */
MX_LWIP_Process();
}
/* USER CODE END 3 */
}
And my webbserver host directly. I like it. So yes. it was the "const" datatype that causing this error.
By replacing Ethernet MAC onto RAM instead of FLASH. Is this a bug in STM32CubeIDE firmware for STM32F407 series?
Thank you so much.
2023-01-03 11:26 PM
Hi,
It's an applicative bug, in 2 applications :
Will be fixed in next F4 maintenance release.
In general, User should be aware for STM32F405xx/07xx and STM32F415xx/17xx series, that Ethernet has no access for flash, To avoid this kind of bugs.
Regards
Mahdy
2023-01-04 01:53 AM
Great!
Also fix this. I can only select "fsdata_custom.c". Looking forward for Week 23 this year. Thank you so much :)
2023-01-04 04:31 PM
> It's an applicative bug
@Mahdy Sghaier , as always about non-trivial topics, you are again talking nonsense. The FLASH is used for storing const data, and const data is not some rarely used feature, but is used extensively everywhere. For example, the applications "httpd", "lwiperf" and others provided together with lwIP are outputting const data without copying and lwIP are actually passing those buffers to the driver. What do you offer? To rewrite them all? What to do in the case of large data, which doesn't fit in RAM? Implement a custom memory copy split in blocks? Duplicate a similar code for every service that needs sending of const data?
Obviously the sane solution here is to make an exception for these buffers in the lwIP driver. The function low_level_output() should check the address of the buffer and, if it is in the FLASH memory range, then allocate a PBUF from SRAM, copy the data to it from the original PBUF, release the original PBUF and do not increment the reference count on the newly allocated PBUF. Actually, if the buffer address is compared to be below the SRAM base (0x20000000), the same code would work for FLASH, CCM and System/OTP/option bytes memories. Also similarly a solution for DTCM/ITCM access on H7 and ITCM access on F7, can be made, but that is not critical.
Therefore, yes, this is a deficiency of the lwIP driver, and a pretty severe one. Note that this issue is relevant not only for F407/F417 devices, but also for F2 devices, when the reworked driver will be enabled for that series.
2023-01-04 04:36 PM
> With FreeRTOS, the connection was slow, or sometimes my webbserver did not responds. It was due to threads doing something else. Sometimes it works, sometimes not.
No, it fails because it is utterly broken, especially regarding the multi-threading. All of it has been reported in my topic for years...
2023-01-05 04:33 AM
Any sensible solution?
2023-01-05 04:38 AM
Can you show us how to solve the issue?
2023-01-05 04:39 AM
I never use FreeRTOS with STM32. It works good for small projects, but when the project requries large memory, then FreeRTOS don't want to run sometimes. It's like it is bussy with something else.
2023-01-05 06:44 PM
No, the problem is not in a FreeRTOS. It just shows that you have not learned the development of multi-thread software and therefore your code is broken.
2023-01-05
06:51 PM
- last edited on
2024-01-03
11:59 AM
by
Lina_DABASINSKA
My previous post is literally a detailed instruction of what must be done to solve this issue. And what do you mean by "show"? I'm not going to write a code for you! By the way, it takes less time to develop that code than it took me to write the previous post...