Assertion failure in rtems_semaphore_delete using lwIP
Isaac Gutekunst
isaac.gutekunst at vecna.com
Thu Dec 10 19:42:13 UTC 2015
Hi All,
We're still debugging some crazy issues related to our unreleased STM32 BSP and lwIP.
We've been pounding on this for a while and are quite stuck. I'm posting this in the hopes
these errors will ring some bells, and that someone can point me in the right direction.
The lwIP version works perfectly using the same HAL on freeRTOS. There is some problem related
to RTEMS or our glue logic.
We have a implemented an lwIP driver using the Ethernet MAC in the STM32F756 processor. We are
consistently getting one of two failures:
1)
An assertion fails in thredqenque.c:126
_Assert( _Thread_Wait_flags_get( the_thread ) == THREAD_QUEUE_BLOCKED );
I've replace the assertion with this code:
if ( _Thread_Wait_flags_get( the_thread ) != THREAD_QUEUE_BLOCKED ) {
asm volatile("BKPT\n") ;
}
The value of the_thread->wait.flags is 0x404U which is equal to
THREAD_WAIT_STATE_READY_AGAIN | THREAD_WAIT_CLASS_OBJECT
2)
We get an error caused by a call to rtems_semaphore_delete. The stack looks as follows:
_Terminate() at interr.c:39 0x802e93a
_CORE_mutex_Seize_body() at coremuteximpl.h:255 0x802c04c
_API_Mutex_Lock() at apimutexlock.c:35 0x802c290
_RTEMS_Lock_allocator() at apimutex.h:120 0x802a53a
_Objects_Allocator_lock() at objectimpl.h:1,016 0x802a570
rtems_semaphore_delete() at semdelete.c:48 0x802a654
sys_sem_free() at sys_arch.c:91 0x80094e2
netconn_free() at api_msg.c:667 0x800ebda
netconn_delete() at api_lib.c:116 0x800de7e
lwip_accept() at sockets.c:354 0x80068ea
http_server_socket_thread() at httpserver-socket.c:186 0x8000f12
_Thread_Handler() at threadhandler.c:95 0x806fbde
_User_extensions_Thread_exitted() at userextimpl.h:244 0x806fb78
This is the code that causes the terminate:
coremuteximpl.h:255
if ( _CORE_mutex_Check_dispatch_for_seize( wait ) ) {
_Terminate(
INTERNAL_ERROR_CORE,
false,
INTERNAL_ERROR_MUTEX_OBTAIN_FROM_BAD_STATE
);
Regards,
Isaac
P.S.
We have a Lauterbach Trace32. It's pretty sweet, and gives us full instruction trace at 50MHz.
If there is a particular area we should look for in the trace data? Also, if anyone wants to
look at the trace data, I can upload the (massive) files somewhere.
--
Isaac Gutekunst
Embedded Systems Software Engineer
isaac.gutekunst at vecna.com
www.vecna.com
More information about the users
mailing list