Assertion failure in rtems_semaphore_delete using lwIP
isaac.gutekunst at vecna.com
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.
> #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.
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:
>> ---|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