On Tue, Jul 19, 2022 at 7:47 AM Fotis Panagiotopoulos <f.j.pa...@gmail.com> wrote:
> Hello! > > I am using Ethernet on an STM32F427 target, but I am facing some issues. > > Initially the device works correctly. After some hours of continuous > operation I completely lose all network communications. > Trying to troubleshoot the issue, I enabled assertions and various other > debug features. > > Again the device works correctly for some hours, and then I get a failed > assertion at stm32_eth.c, line 1372: > > DEBUGASSERT(dev->d_len == 0 && dev->d_buf == NULL); > > No other errors are reported (e.g. stack overflows etc). > > > I have observed that this issue usually manifests itself when there is > insufficient stack on a task. > But in my case, all tasks have oversized stacks. Typically they do not > exceed 50% utilization. > I have plenty of room available in the heap too (> 100kB). > > Regarding the rest of the firmware, I cannot see any other misbehaviour or > problem. > I haven't ever seen any other unexplained problem, assertion fail, > hard-fault etc. > The application code passes all of our tests. > In fact, even when this issue happens, although I lose network > connectivity, the rest of the system works perfectly. > > Please note that I have checked the contents of dev->d_len and dev->d_buf, > and they seem to contain valid data. > The address lies within the normal address space of the MCU, and the size > is sane. > So it doesn't look like any kind of memory corruption. > > > At this point I believe that this is an actual bug either on the STM32 MAC > driver, or at the TCP/IP stack itself. > I had a look at the driver code, but I didn't see anything suspicious. > > > Has anyone observed the same issue before? > Can it be affected in any way with my configuration? > Or maybe, do you have any recommendations on what to test next? > > > Thank you! I am currently working on a networking device and trying to get it working more robustly. My device is using a different ARM- based micro. I have seen that when I enable the network debugging features, it seems to hit an assertion failure before getting to nsh prompt at startup. This was on a quite recent master. I haven't had a chance to diagnose this further. Have you tried enabling these and if so, do they work? Also, out of curiosity, have you tried running ostest on your board? Thanks, Nathan
