Crash in uxListRemove on Ameba Board

muratcakmak wrote on Monday, August 07, 2017:

I saw similar topics but non of them helped me.

I am working with Ameba IoT board and Ameba SDK v4.0. I have an application which connects to AWS Cloud using AWS SDK, mbedtls and LwIP.
FreeRTOS v8.2 is used.

I am seeing errornous addresses in uxListRemove which crashes the system.
configAssert is defined.
I tried to change configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY and it is 1 now.
configAssert called for Priority Grouping
configASSERT( ( portAIRCR_REG & portPRIORITY_GROUP_MASK ) <= ulMaxPRIGROUPValue );

In fail case portAIRCR_REG & portPRIORITY_GROUP_MASK value was 768
ulMaxPRIGROUPValue value was 256

Therefore I called " NVIC_SetPriorityGrouping( 0 );" and I passed the configAssert() but still crashes in uxListRemove.

What problem can be? Any suggestion?

Thank you
Murat Cakmak

rtel wrote on Monday, August 07, 2017:

Sounds like you are doing the right things.

My first suggestions would be to obtain the latest FreeRTOS code from
the public SVN repository on SourceForge: That contains
even more asserts that will help with interrupt priority issues - if
that is indeed the issue.

Do you also have stack overflow detection turned on? If not then please
turn that on too:

Finally, I’m afraid I don’t know where to start with lwIP as there are
lots of options there, but most issues can be traced to the driver code,
as that is different in each system so not so well tested. Make sure
you are following the lwIP threading requirements. Who created the port
to the Ameba board? Please post a link to the board.

muratcakmak wrote on Tuesday, August 08, 2017:

Hello there, thank you.

Stack overflow is enabled. There can be a stack overflow which masked by hard fault, not sure.

Why there is not an internal protection in uxRemoveList?
I saw some FreeRTOS modification as a workaround.

Can similar modification be applicable to solve the issue instead of fighting with huge amount of different modules (lwIP, mbedtls, our specific user app etc)?

muratcakmak wrote on Tuesday, August 08, 2017:

I am asking for FreeRTOS modification because there can be a problem with an specific ISR which set in a library.

Generally when I do backtrace for an assertion, root function is an ISR function

1 vAssertCalled (ulLine=389, pcFile=) at …/Boards/AmebaSDK/project/realtek_ameba1_va0_example/inc/FreeRTOSConfig.h:221
2 vPortEnterCritical () at …/Boards/AmebaSDK/component/os/freertos/freertos_v8.1.2/Source/portable/GCC/ARM_CM3/port.c:389
3 xQueueGenericReceive (xQueue=, pvBuffer=pvBuffer@entry=, xTicksToWait=xTicksToWait@entry=10000, xJustPeeking=xJustPeeking@entry=0) at …/Boards/AmebaSDK/component/os/freertos/freertos_v8.1.2/Source/queue.c:1219
4 xTaskRemoveFromEventList (pxEventList=pxEventList@entry=) at …/Boards/AmebaSDK/component/os/freertos/freertos_v8.1.2/Source/tasks.c:2474
5 xQueueGenericSendFromISR (xQueue=, pvItemToQueue=pvItemToQueue@entry=, pxHigherPriorityTaskWoken=pxHigherPriorityTaskWoken@entry=, xCopyPosition=xCopyPosition@entry=0) at …/Boards/AmebaSDK/component/os/freertos/freertos_v8.1.2/Source/queue.c:1152
6 _freertos_up_sema_from_isr (sema=) at …/Boards/AmebaSDK/component/os/freertos/freertos_service.c:132
7 rtw_up_sema_from_isr (sema=) at …/Boards/AmebaSDK/component/os/os_dep/osdep_service.c:484
8 lextra_bus_dma_Interrupt (data=) at …/…/…/component/common/drivers/wlan/realtek/src/osdep/freertos/lxbus_intf.c:118

lextra_bus_dma_Interrupt is in a library (lib_wlan.a) and I cannot see the source file and who sets the priority.

muratcakmak wrote on Tuesday, August 08, 2017:

I had some concerns about Memory overflow but probably does not have. Because there are two different Memory Internal SRAM and SDRAM. All freertos is in the Internal SRAM. I moved it to SDRAM and still same issue.
According to your feedbacks, only reason can be interrupt priorities.

I also disable all interrupts using __disable_irq() __ from core_cm3.h in uxListRemove function but does not solve.

muratcakmak wrote on Monday, August 14, 2017:

It seems my issue was completely different. It was about conflict between two different timer function which one of them uses FreeRTOS timers and pass wrong values. So, it is completely implementation custom SDK specific.