This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM2434: AM2434 + MCU+ SDK 11.00.00.15 — LwIP/FreeRTOS assert in sys_arch_protect_nesting under RX load

Part Number: AM2434
Other Parts Discussed in Thread: SYSCONFIG

We are seeing a stability issue when using LwIP (CPSW) with FreeRTOS on AM2434 (MCU+ SDK). Under heavy RX traffic, the system frequently stops in an assert inside LwIP’s FreeRTOS port:

sys_arch.c (around line 191)

LWIP_ASSERT("unexpected sys_arch_protect_nesting", sys_arch_protect_nesting > 0);

Observed behavior

  • The issue reproduces even with low RX load; the probability of hitting the assert increases with RX traffic volume.
  • The assert indicates that sys_arch_unprotect() is being called when sys_arch_protect_nesting is already 0 (i.e., the nesting counter appears to go out of sync).
  • We reviewed the call flow and also checked the generated assembly around the increment/decrement, but it seems ok.
  • Another possibility is an extra unprotect, but when tracing sys_arch_protect() / sys_arch_unprotect() and monitoring sys_arch_protect_nesting , everything looks consistent until the point where the counter becomes inconsistent.

Workaround / mitigation

We tried to guard the increment/decrement of sys_arch_protect_nesting with a critical section and taking care of cache coherency but no luck. We were able to eliminate the issue by changing the macro:

LWIP_FREERTOS_SYS_ARCH_PROTECT_USES_MUTEX = 0

With this setting, the port uses a critical section (interrupt masking up to syscall priority) instead of a mutex for sys_arch_protect() / sys_arch_unprotect() . Given that these protect/unprotect regions are typically small and frequent, we also suspect the mutex-based approach may add unnecessary overhead and additional context-switch complexity under load.

Questions

  1. Is this a known issue in the MCU+ SDK LwIP FreeRTOS port for AM243x?
  2. Is setting LWIP_FREERTOS_SYS_ARCH_PROTECT_USES_MUTEX to 0 considered a correct/endorsed solution, or is there a recommended fix/patch/configuration we should apply instead?
  3. Are there specific LwIP/FreeRTOS configuration constraints (e.g., priority settings, interrupt priorities, cache coherency expectations) that could lead to this behavior?

File references

  • source/networking/lwip/lwip-port/freertos/src/sys_arch.c
  • source/networking/lwip/lwip-port/freertos/include/lwipopts_os.h

Development environment

  • MCU+ SDK: 11.00.00.15
  • Compiler: TI ARM CLANG 4.0.4 LTS
  • SysConfig: 1.26.0
  • CCS: 20.40
  • Device: AM2434 (Cortex-R5F_0-0)
  • Hi Roberto,

    We have not encountered this issue in our testing, at least not in low traffic throughput in my memory. What is the time scale that you are observing this issue being seen? I can try setting up a test bench to try and reproduce this issue. 

    Ideally, we do not recommend removing mutex protection for the OS ports. This will prevent issues presenting themselves in other unexpected manner. I have to run this through our internal experts to get a better grasp on this. 

    Is this issue seen in one of the out of box examples that we provide? Is this seen in custom application that you developed? Details on any additional processes running in the environment will give better context about the issue.

    Thanks and regards,
    Teja.

  • We encountered this issue on our custom application running mDNS + MQTT client and tracealyzer running in streaming mode on UART

  • Hi 

    This is something we have not observed in our testing with default examples. I will check with our internal team to run a check if the disabling mutexes is acceptable for our environment. Please give us 4-5 working days to look into this issue.

    Thanks and regards,
    Teja.

  • Hi Roberto 

    Teja is out on business trip this week. Responses will be further delayed. Please expect response early next week if not sooner. Thanks. 

  • Hi Roberto,

    After some examination, Our teammates have found that the default configuration in LwIP for LWIP_FREERTOS_SYS_ARCH_PROTECT_USES_MUTEX is set to 0, indicating that it is tested and working. This setup expects the critical sections to be shorter and could invoke critical sections which will block all other interrupts in the system.

    So, if your case needs very high real-time performance, we might have to explore some other way to achieve this. But based on results of the application behavior with the macro set to '0', you can decide further. From TI side, we don't have any specific requirements that this macro should always be 1.

    Please let us know the results and observations in your testing so that we can identify the follow up actions.

    Thanks and regards,
    Teja.