Assertion failure in rtems_semaphore_delete using lwIP

Isaac Gutekunst isaac.gutekunst at
Wed Dec 16 22:44:47 UTC 2015

I've managed to get the board to crash more quickly this time around.

The priority of all interrupts appears to be 0xD0.


The board will also crash without any interrupts installed as far as I can tell.

The Lauterbach probe indicates all interrupts are disabled, and yet strange things are happening.

Apologies for the apparent non-sequitur comments with regards to testing. Changing one small 
thing appears to result in slightly different timing making a seemingly arbitrary different 
part of code to fail. Also thanks for all the different advice.

| New suspect		       |

I'm starting to suspect SysTick.

A while back I said most of the test cases where passing. I don't think this is actually true.

I thought maybe the SysTick priority is wrong, but at least according to the Lauterbach tool 
all the interrupts are 0xD0. However, I'm not sure if the Exceptions/Traps are listed.

Would it be a problem if the SysTick or SVC handler had a priority that was too high? I really 
doubt that's going on, but I'm grasping at straws here.


P.S. Here is the earlier thread:

> No, this doesn't look good. According to the stack trace you are in
> thread context. However, we have executing != heir and
> dispatch_necessary == true. This is a broken state itself. I guess,
> something is wrong with the interrupt level so that a context switch is
> blocked. On ARMv7-M this is done via the system call exception.

On 12/11/2015 04:35 PM, Sebastian Huber wrote:
> ----- Am 11. Dez 2015 um 16:58 schrieb Isaac Gutekunst isaac.gutekunst at
>> Hi Sebastian,
>> Yes it still is.
>> We've put a data watch point on thread dispatch disable level becoming -1.
> Ok, this is good.
>> Here is one case where it happens:
>> -000|Thread_queue_Unblock_critical
>> -001|Thread_queue_Extract_critical
>> -002|CORE_message_queue_Dequeue_receiver
>> -003|CORE_message_queue_Submit
>> -004|CORE_message_queue_Send
>> -005|rtems_message_queue_send
>> -006|sys_mbox_post
>> -007|tcpip_apimsg
>> -008|netconn_recved
>> -009|lwip_recvfrom
>> -010|lwip_read
>> -011|http_server_serve
>> -012|http_server_socket_thread
>> -013|Thread_Handler
>> -014|Thread_Handler
>> ---|end of frame
> Now, you just have to look at the instruction trace and see what happened between entering rtems_message_queue_send() and the watchpoint.  I guess an interrupt happened and did something wrong.
> What is the priority of your stm32f_ethernet_isr() interrupt IPR register field value?

More information about the users mailing list