2024-06-29 03:49 AM - edited 2024-06-29 03:52 AM
Hi,
Since before I have used USART for sending data with protocol buffers and SLIP encoding, thought that I should try to move over to Ethernet and UDP instead. It became harder than I thought, to say the least.
I'm using STM32CubeMX 6.8.1.202304191431 for generation.
I can get the ping to work without FreeRTOS, as soon as I add FreeRTOS, ping stops working.
ETH Configuration:
MPU Config:
lwIP Config:
Bottom of my STM32F767ZITX_FLASH.ld :
.lwip(NOLOAD) :
{
. = ABSOLUTE(0x2007c000);
*(.RxDecripSection)
. = ABSOLUTE(0x2007c0a0);
*(.TxDecripSection)
} >RAM
.ARM.attributes 0 : { *(.ARM.attributes) }
}
My main-function looks like:
#include "main.h"
#include "lwip.h"
void SystemClock_Config(void);
static void MPU_Config(void);
static void MX_GPIO_Init(void);
extern struct netif gnetif;
int main(void)
{
MPU_Config();
SCB_EnableICache();
SCB_EnableDCache();
HAL_Init();
SystemClock_Config();
MX_GPIO_Init();
MX_LWIP_Init();
while (1)
{
ethernetif_input(&gnetif);
sys_check_timeouts();
}
}
No problem to ping the device.
Now adding FreeRTOS to the mix:
Changed these settings in FreeRTOS:
USE_NEWLIB_REENTRANT Enabled
MINIMAL_STACK_SIZE 512
TOTAL_HEAP_SIZE 64000
Interface: CMSIS_V2
ETH Changes:
RX Mode: Interrupt Mode
NVIC Enabled Ethernet global interrupt preemption priority 5
No changes to: STM32F767ZITX_FLASH.ld from before with No-OS.
SYS:
Timebase Source: TIM6
lwIP some of the settings changed, it enabled OS-Mode for lwIP. (I haven't actively changed any):
WITH_RTOS (Use FREERTOS ** CubeMX specific **): Enabled
CMSIS_VERSION (CMSIS API Version used): CMSIS v2
RTOS_USE_NEWLIB_REENTRANT (RTOS used - 1): Enabled
NO_SYS (OS Awarness): OS Used
In main.c:
#include "main.h"
#include "cmsis_os.h"
#include "lwip.h"
osThreadId_t defaultTaskHandle;
const osThreadAttr_t defaultTask_attributes = {
.name = "defaultTask",
.stack_size = 512 * 4,
.priority = (osPriority_t) osPriorityNormal,
};
void SystemClock_Config(void);
static void MPU_Config(void);
static void MX_GPIO_Init(void);
void StartDefaultTask(void *argument);
int main(void)
{
MPU_Config();
SCB_EnableICache();
SCB_EnableDCache();
HAL_Init();
SystemClock_Config();
MX_GPIO_Init();
osKernelInitialize();
defaultTaskHandle = osThreadNew(StartDefaultTask, NULL, &defaultTask_attributes);
osKernelStart();
while (1)
{
}
}
void StartDefaultTask(void *argument)
{
MX_LWIP_Init();
for(;;)
{
osDelay(1);
}
}
If I pause the execution the program hasn't crashed, it seems to be running.
CubeID Projects was huge so I didn't attach these but if they are needed, ask and I will solve it.
It feels like I have missed something in my understanding how this works.
In the No-OS Mode I call ethernetif_input(...) and sys_checks_timeouts() which calls the lwip-stack. However, with FreeRTOS implementation I don't do this, but it is my understanding looking in the code that it should create a lwip task that handles the stack so I think I shouldn't need to call anything to get it working with ping?
I have also tried an example with NetCONN FreeRTOS for F767ZI and it works to ping the device with it, that example is unfortunately not generated with CubeMX I think?https://github.com/STMicroelectronics/STM32CubeF7/tree/master/Projects/STM32F767ZI-Nucleo/Applications/LwIP/LwIP_HTTP_Server_Netconn_RTOS
2024-06-29 05:43 AM
I'll suggest you to try with MDKARM or EWARM IDEs. for me also Ethernet is not getting pinged when i use CubeIDE but same code with same configuration is working with MDKARM and IAR work bench
2024-06-29 07:57 AM
Thanks for your reply!
This is just a hobby and I guess those IDE's are licensed and not free?
I usually compile in WSL with a CMake environment I have created from the Makefile output from CubeMX.
I tried to just fastly generate Makefile output and tried to make it. Then I get a fault from the linker:
/opt/arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: warning: build/Test.elf has a LOAD segment with RWX permissions
collect2: error: ld returned 1 exit status
So something is different here, I tried my own CMake environment as well and then I got the non-OS to only reply on 1 ping out of 4 directly after Reset.
So seems like I get different results by changing environment, need to look into this more when I have the time.
2024-06-29 12:38 PM - edited 2024-06-29 12:42 PM
> ld: warning: build/Test.elf has a LOAD segment with RWX permissions
Ignore this warning, it should be removed in some future version.
CubeMX can now create a CMake project directly. So you maybe used a different CubeIDE version, with a different toolchain, maybe with a different Cube library package. This is a notable difference .
2024-06-29 04:19 PM
Thanks, I saw some posts about when I sat down again.
The main problem with the makefile generated project was due to CubeMX generating these two lines in C_SOURCES
Drivers/BSP/Components/lan8742/lan8742.c \
Drivers/BSP/Components/lan8742/lan8742.c \
I tried downgrading CubeMX to 6.8.1 and ARM GNU Toolchain to 12.3.rel1.Running from WSL, I did actually not even get it working without OS this time. Sometimes I get one ping reply directly efter Reset of the Nucleo board, this makes me feel that I miss to clear something after a receive.
I had some different versions installed but I tried upgrading everything:
CubeMX to the latest: 6.11.1,
ARM GNU Toolchain to 13.2.rel1
Running in WSL I don't get either No-OS or FreeRTOS version to work.
Re-installed CubeIDE to the latest 1.15.1 in Windows (CubeIDE 1.12.1. before).
CubeMX 6.11.1
Only get one reply directly after reset when pinging in No-OS mode, no reply for RTOS mode.
It feels like I'm missing something.
2024-06-30 04:32 AM - edited 2024-06-30 05:09 AM
Unfortunately, the ETH driver in the Cube library still has some subtle bugs, and projects generated by Cube (or templates) still may have issues. Until this gets fixed, ETH is hard to start with. (not even mentioning the RTOS issues ). Try to find a *ready* example project, test and adapt it gradually. Look into differences in ethernetif.c for RTOS vs. non-RTOS.
2024-06-30 03:24 PM
Yeah I'll have to look into that.
The LwIP_HTTP_Server_Netconn_RTOS works perfectly with ping at least.
Tried to look through ethernetif and lwipopts much is alike but not all and they are written differently so not as straight-forward to copy-paste. Tried specifiying Heap pointer for lwIP but no success on that part.
Also tried to check the MCU configurations for MPU, ETH, RCC, etc but no luck there when I changed to the same. Tried setting up an UDP client and see if it could send messages to my UDP server, single messages could get through on reset but often not at all.
When I reset and look at the traffic with wireshark I always see the first two rows (on one occasion I saw the third row.):
5 2.148204 STMicroelect_00:00:00 Broadcast ARP 60 Who has 192.168.0.20? Tell 192.168.0.40
6 2.148258 HP_82:c2:92 STMicroelect_00:00:00 ARP 42 192.168.0.20 is at 6c:02:e0:82:c2:92
7 2.148844 192.168.0.40 192.168.0.20 ECHO 60 Response
where 192.168.0.40 is the Nucleo-board and 192.168.0.20 is my computer. After that 192.168.0.40 never sends anything again.
We will see if I will have the time to look into this further or just leave it at this, I have a rather "ok" solution over serial port and SLIP encoding, just thought it would be fun to have UDP instead and perhaps have possibility for higher speed. But this Ethernet part really was like hitting a wall :)
2024-06-30 03:38 PM
The two first rows are ARP request and reply. It is not clear why we see the echo response from the PC but don't see the request.
2024-06-30 11:53 PM
I did a retake configuring without OS.
It works with ping.
I then tried to activate CMSISV_1, it works with ping!
I then switch to CMSISV_2, now it doesn't work :(
Got the idea after reading this post:
https://community.st.com/t5/stm32-mcus-embedded-software/steps-to-enable-udp-and-tcp-protocol-ethernet-with-freertos-lwip/m-p/662686
Also got CMSISV_1 and not CMSISV_2 to work. Maybe need to check the usage of os* specific commands in ethernetif.c.
The working example for HTTP server with NETCONN and FreeRTOS also uses CMSISV_1.
2024-08-31 12:01 AM
Think I found the solution to this, it had to do with my heap sizes. When I lowered my TOTAL_HEAP_SIZE to 81920 for FreeRTOS it started working. I had almost the double before.
Thought I had the space for it but I think I'm a little uncertain to what is allowed memory wise.