Assertion failure in rtems_semaphore_delete using lwIP

[Isaac Gutekunst]

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

The priority of all interrupts appears to be 0xD0.

> #define BSP_ARMV7M_IRQ_PRIORITY_DEFAULT (13 << 4)


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.

Isaac

P.S. Here is the earlier thread: https://lists.rtems.org/pipermail/devel/2015-October/012740.html


> 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 vecna.com:
>
>> 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?
>