I'm facing an ethernet project design based on STM32F207 MCU. The firmware runs a server (TCP or UDP servers) that is constantly asked by 1 to 10 clients. Request and answer payload are less than 20 bytes. Before the custom PCB was produced the server was developed and tested on its corresponding nucleo board. But tests were based on 1 remote host connection as a client to the nucleo server by a local network.

After this moment, a PCB prototype production was done so we could test and validate this PCB design. The PCB was exactly working as Nucleo did. From here, firmware development and debugging continued within the custom hardware.

When we tried to add more clients -in a nonstop way test- the application works correctly during some hours before getting a "hardfault". The great part of times, it was the stop working event. We were unable to trace this hardfault, or surelly we don't know how to trace it.

I would like to ask for a thinking that is incoming to my head and I have not found any data about this:

Talking with someone, this person says to me that putting a server with multiclient connections in a microcontroller is a very big challenge, due they are not processors neither uProcessors (powerful and higher performance devices compared to cortex-m3 like stm32f2). CPU could be "collapsed" by this kind of applications.

Hearing this, I tried to look for people who deals with "servers on microcontroller with multi-clients connections" or give its suggestions about this. But I have no success. I have seen that there is no examples, a lot of developers asking for help at the same point with not solved situations, no evidence of a working demo, etc.. Even I opened a ticket with ST stuff (I'm waiting for their answer).

I'm looking for some ethernet embedded expert that gives me answers about this question. Someone who tells me from its experience if he did a server with multi connection with success in a microcontroller like this. It will be appreciate if someone brings me related documentation/webpages about that implementing this kind of applications on microcontroller could easily hang its CPU or not.

I need some evidence that multiclient in a stm32f207 asking for requests to the server could be supported.

Are someone with experience on this here?


As it seems to be concerning and it could useful for readers in order to talk about this situation, I decided to add here the particular requirements of this server application what I'm talking about.

We made the simpler server application from echo server demo given by ST: client requests with a byte and server answering 16 bytes. Then we add read or write 16 digital input or digital output (using HAL write/read functions) depending on command byte received into every client request.

We were having same issue with TCP server and UDP server, using freeRTOS plus netif, using HAL layer, and we have been using LwIP stack as suggested by ST, now we are not using FreeRTOS due we are not very experienced on this and we were unable to deal with advanced level FreeRTOS handling. So we tried to change to a non RTOS strategy and we are working with RAW API.

Server Application details:

  • We would connect from 1 to 10 clients.
  • Every client would be sending requests to the server 100per/sec (but it could be slower if this ratio is too much for this server).
  • Client only stops requests once it is disconnected from the server.
  • Every client request has less than 20 bytes of data payload,
  • When server receives a request the MCUreads/writes some GPIOs, then; server musts answer immediately to the client request with the result into a 16bytes data payload.
  • Now we are trying this with TCP and UDP server. The same result.
  • I defined pool options for statical buffers.
  • Server is configured with RxMode = polling mode.
  • Client is made with python running on remote host with Windows and clients are executed from windows cmd.

I'm working on understanding and calculating the correct and optimal lwipopts.h options. I'm also working on HAL_Ethernet defines for MAC frames handling.

I'm sure optimal configuration could improve some resource issues. But not sure if it will solve our hard fault problem.

  • 2
    \$\begingroup\$ it's a challenge but not impossible. But this is too vague to be capable of being answered clearly. Are you using an RTOS? are you using a library such as lwIp? what kind of requests do you need to service and what kind of computation is required to produce a response? can requests overlap or occur concurrently? and so on. You need to do a lot more definition of requirements before you can hope to get a useful answer. \$\endgroup\$
    – danmcb
    Jun 8, 2023 at 13:51
  • 2
    \$\begingroup\$ by the way if you are getting hard fault, make sure that your fault handlers are properly implemented and giving some kind of useful debug info. your problem might be nothing to do with the ip server app at all. you do need to track this down to get a reliable design. \$\endgroup\$
    – danmcb
    Jun 8, 2023 at 13:53
  • 3
    \$\begingroup\$ Just questioning why a microcontroller is not a processor or microprocessor to you? Just debug where the hard fault is. You have a software issue likely somewhere. \$\endgroup\$
    – Justme
    Jun 8, 2023 at 14:24
  • 2
    \$\begingroup\$ If your networking stack and whatever code you write is written & configured correctly, then there's no reason for your MCU to not be able to support multiple clients. HardFaults caused by firmware are always traceable - if you know where to look for the useful info and how to interpret it. \$\endgroup\$
    – brhans
    Jun 8, 2023 at 14:41
  • 3
    \$\begingroup\$ In my experience, HardFaults caused by attempts to execute code from invalid memory addresses are most often caused by stack corruption. Stack corruption is most often caused either because you simply have not allocated enough space for the task's stack and it's overflowing into some other memory area, or because you've allowed a buffer overrun in a local variable, for example allocating an array[x] and then trying to write to array[x+n]. \$\endgroup\$
    – brhans
    Jun 8, 2023 at 15:24

1 Answer 1


I would like to explain that I've applied a change that has solved the hardfaults of my application. It has even solved net link sudden disconnections at UDP server version. TCP version server doesn't get any hardfault anymore but it has net links disconnections.

I must to say, by the way of searching answers and "how to" at community, testing, debugging, register value checking, etc; we have found the confirmed evidence of some bugs that cubeMx tool creates adding LwIP stack when generate the project (source code files, folders, configuration settings source code, etc.).

Some of them can be solved and surely there stills having other ones we don't have yet identified. It can be explained in that post link st community link about ethernet bugs

But changes we made related to found bugs didn't solve the hardfault situations at all.

Someone tell me that he was dealing the same issue with the same hardware than me. He explains me that his solution was based on reducing the HCLk frequency. The key is not to work at maximum speed value of the MCU clock: 120 MHz, he said.

I don't know why. I didn't read any advice from ST documentation about not to use the maximum allowed value. I don't think 120 MHz should be avoided. Surely it has another explanation. But nowadays I don't have an answer.

So I decided trying to use less than 120 MHz HCLK at see what happens. Obviously it also lowered the peripheral bus clocks. I let the clock system in that way:

gpraphical clock configuration

Sorry because I have no theoretical explanation for this solution. I don't know why this makes the application works and why it is avoiding hardaults and avoiding net links disconnections. So feel free to add any possible explanation.

But it seems to solve hardfaults I was getting. I have 5 clients asking to the server, with a total ratio of 850 commands per sec. 3 days working and it doesn't stop yet. No hardfault, no link disconnections.

I think this test result is answering my main question. From now on server should be improved touching the correct keys (and settings) for getting a TCP server version working without disconnecting.

  • \$\begingroup\$ Yo are right. My apologies. It was an edition errata. I probably unconsciously removed "M" character. \$\endgroup\$
    – Suvi_Eu
    Jun 21, 2023 at 10:09
  • 1
    \$\begingroup\$ No worries. Just wanted to avoid confusion. \$\endgroup\$
    – winny
    Jun 21, 2023 at 10:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.