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