0

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?

Edit

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.

Suvi_Eu
  • 777
  • 6
  • 19
  • 2
    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. – danmcb Jun 08 '23 at 13:51
  • 2
    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. – danmcb Jun 08 '23 at 13:53
  • 3
    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. – Justme Jun 08 '23 at 14:24
  • My question is regarding if a microcontroller like this, stm32f207 is multiple client compliant or not (with the propper strategy, of course). Te most existing work is about unique client. And some one told me that multiple connections could be better handled with powerfull microcontrollers. Independently of I had hardfaults or not. But I haven't any reference according this paradigm except this college. – Suvi_Eu Jun 08 '23 at 14:28
  • @Justme this is what I'm trying at every hardfault. It was untrackable for me. I asked for help about how to improve this hardfault source research. But I asked this and I'm dealing with this issue in other post. Here I would like to ask for opinions, suggestions and talking about multiclient connections on microcontrollers capabilities according to other's developer's experience doing this. Thanks for your attention. – Suvi_Eu Jun 08 '23 at 14:32
  • 2
    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. – brhans Jun 08 '23 at 14:41
  • @damncb if you agree I could give the requirements if it helps you to give me an useful answer: we are having same issue using TCP server, UDP server, with freeRTOS plus netif, without RTOS, we are using HAL layer, and we were ever using LwIP stack, as suggeted by ST. 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 it's needed), request has 20 bytes of data payload, when server receives every request the mcu reads/writes some GPIOs and server musts answer immediately to the client request with the result (16B). – Suvi_Eu Jun 08 '23 at 14:50
  • 2
    Why was hardfault untrackable? How did you try to trace it? How far you managed to trace it and at what point it became untrackable? – Justme Jun 08 '23 at 14:53
  • @Justme Disassembly view, stack trace view. We even watch cortex m3 register where address of hardfault source is written. The address usually is out of code range and going there appears this message "can nor acces memory at address xAddVal". At thread stack view it appears () at xAddVal. When click there it gives me nothing. But I'm now talking not remembering too well. The next hardfault I will take a print screen and I will tell you better my strategy. I hope you could help me with the correct way. – Suvi_Eu Jun 08 '23 at 15:03
  • 2
    @Suvi_Eu - Hi, Re: "*I'm looking for some ethernet embedded expert that gives me its opinion or bring me related documentation [...]*" Please remember that this site is not designed for discussion & opinions here. For example, from [here](/help/dont-ask): "*Chatty, open-ended questions diminish the usefulness of our site and push other questions off the front page.*" and one of the possible [closure reasons for questions](/help/closed-questions) is "opinion based". Don't be surprised if this question gets closed, as it's currently *very* open-ended & lacking specific detail . – SamGibson Jun 08 '23 at 15:21
  • 3
    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]. – brhans Jun 08 '23 at 15:24
  • 1
    @SamGibson thanks for your advice, I have changed this to a propper way to ask for this. – Suvi_Eu Jun 09 '23 at 07:05

1 Answers1

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.

Suvi_Eu
  • 777
  • 6
  • 19