System state violation in LwIP sockets API
Posted: Wed Feb 24, 2016 7:01 am
Hey, I'm getting a stack overflow in LwIP after a while (generally after 10 - 30 minutes of handling ~100 byte messages that are sent to the device every two seconds). Trying to diagnose this, I turned on the system state checking, and get a system state violation (SV#10).
I had a look, and it turns out the problem is the call in sys_sem_signal_S(...) (in sys_arch.c), because the system doesn't go into a lock state unless LwIP's SYS_LIGHTWEIGHT_PROT option is switched on (setting that causes the sys_arch_protect() and sys_arch_unprotect() functions to get called).
And then, it seems like the stack overflow isn't happening. So should I just leave SYS_LIGHTWEIGHT_PROT on, or is there some disadvantage to doing that?
I have not tried yet changing the call from sys_sem_signal_S(...) to sys_sem_signal(...) in the socket code - but it would be good for that to be properly selected based on the configuration.
One other little thing - during debugging I upgraded from a 3.0 release to the latest 16.1 release and hit some errors - in os\hal\ports\STM32\LLD\SPIv1\spi_lld.c there are a bunch of calls to osalDgbAssert(...) that should be osalDbgAssert(...).
Thanks!
I had a look, and it turns out the problem is the call in sys_sem_signal_S(...) (in sys_arch.c), because the system doesn't go into a lock state unless LwIP's SYS_LIGHTWEIGHT_PROT option is switched on (setting that causes the sys_arch_protect() and sys_arch_unprotect() functions to get called).
And then, it seems like the stack overflow isn't happening. So should I just leave SYS_LIGHTWEIGHT_PROT on, or is there some disadvantage to doing that?
I have not tried yet changing the call from sys_sem_signal_S(...) to sys_sem_signal(...) in the socket code - but it would be good for that to be properly selected based on the configuration.
One other little thing - during debugging I upgraded from a 3.0 release to the latest 16.1 release and hit some errors - in os\hal\ports\STM32\LLD\SPIv1\spi_lld.c there are a bunch of calls to osalDgbAssert(...) that should be osalDbgAssert(...).
Thanks!