STM32F7 - basic LwIP without FreeRTOS

[Piotr Roszak]

Posted on February 09, 2017 at 16:32

Hello,

I am using STM32F769I-DISCO board and CubeMX-generated project (v4.19) for this specific board.

I am having troubles to makeminimal working firmware that can just respond to ping sent from my PC. In CubeMX I configured ETH component in RMII mode, LWiP middleware and clocks. I attached print screens with basic ETH and LWiP configurations.

PC that the board is connected to is in the same IP network, IP addresses and masks are correct.

Clocks in the project are configured in the same way as example working project mentioned below (Ethernet PTP is 200MHz). All the ETH GPIOs have default configuration (all Very High output speed, no pulling).

My main function is default main generated by CubeMX, I just added call to MX_LWIP_Process in the infinite while loop.

int main(void)
{
 /* USER CODE BEGIN 1 */
 /* USER CODE END 1 */
 /* MCU Configuration----------------------------------------------------------*/
 /* Reset of all peripherals, Initializes the Flash interface and the Systick. */
 HAL_Init();
 /* Configure the system clock */
 SystemClock_Config();
 /* Initialize all configured peripherals */
 MX_GPIO_Init();
 MX_LWIP_Init();
 /* USER CODE BEGIN 2 */
 /* 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 */
}�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

After flashing the project and running it, it does not get stuck anywhere. It also does not return any error. It constantly calls

MX_LWIP_Process in the while loop, which is desired behavior.

I also do not use any compiler optimizations.

After flashing LwIP_HTTP_Server_Socket_RTOS example project I was able to ping my

STM32F769I-DISCO board, so I assume that there are no hardware connection problems. IP configuration used in this project was exactly the same as in mine.

Thank you for your help,

Piotr

#ethernet #rmii #lwip #cubemx

[world04]

Posted on February 09, 2017 at 20:51

You are using in eth the RX polling mode. I had never seen this working. I always find the IRQ mode in many examples and i prefere this mode too to prevent loss of frames. Using polling the eth interface instead service them with an ISR is quite more complicated in a  superloop as doing this job as a thread. 

[Piotr Roszak]

Posted on February 13, 2017 at 20:05

Thank you for your response. I used to run RX polling mode on STM32F4 without any problems, so I expected that moving to STM32F7 will be straightforward.

[world04]

Posted on February 13, 2017 at 22:21

Ok, mhh, would you explain me why you use the polling mode instead ISR / DMA? 100Mbit is a respectful speed and produce much data in a short time, that will be overwritten if not saved in time.  I am interessting in the problem you wanna do using polling the ETH interface. Would you write more about it? 

[Piotr Roszak]

Posted on February 14, 2017 at 11:33

I'm using polling mode with DMA and have no performance issues. Application is very simple and just passes data from one interface to another. I thought that polling mode is the simplest mode and should work out of the box. 

[world04]

Posted on February 14, 2017 at 21:28

Thanks for your further detailed description how you use it. 

[Rafa? Kolonko]

Posted on February 15, 2017 at 18:32

There is a bug in this CubeMX LwIP example .You should change PHY address to 0 in stm32f7xx_hal_conf.h.

[Piotr Roszak]

Posted on February 15, 2017 at 19:51

Thanks for your response. Unfortunately, it did not help.

[world04]

Posted on February 15, 2017 at 19:59

That issue is solved in CubeMX 4.19.0 and i had checked them up a few day ago. The example if the echo client works, my BSD socket not, but this seems to be more a knowledge issue instead a bug 🙂

[world04]

Posted on February 15, 2017 at 20:14

I had done some test using eth0 without ISR/DMA and it was unable to catch all incomming ethernet frames in time at 100MBit speed. Some frames where lost or incomplete or the frame sequence where scrambled.

At the next weekend i will do some further tests some other non-ISR methods to get all frames, in time and in order.That's an easy job by using an ISR that calls the dma, but everything other using in polling mode. The main problem is the job dispatcher in a superloop, that's, in normal circumstance an uncontrolled time waster. If a frame comes in and the mcu process an other job, how should  the mcu know that it must break the actual process and save the incomming data, interpret them and answer, before it went backt to the interuppted job an resume them?  

I am unsure is this will work. An RTOS coud not solve this problem alone, but helpfull to schedule  the jobs and shre the available process time. I can assume the a client can open a connection to a host by using a superloop, but an ISR/DMA is a must at 100Mbit to solve the time critical issue.