Issue with TCP Echo Qemu mps2 Demo

Hi I am quite new to FreeRTOS here and am learning about it’s internals.
I am trying to run the Demo FreeRTOS_Plus_TCP_Echo_Qemu_mps2 with no modifications other than the information specific to my network. Trying to run the Demo as I want to build on it to simulate with MQTT on Qemu on linux. I’m currently running Ubuntu 21.10.
I’m finding that the application hangs after recieving an ARP response. After using the traceARP_PACKET_RECEIVED() and iptraceCREATING_ARP_REQUEST( ulIPAddress ) macros I can see that an ARP request goes out but none is received.
When using the Debugger it seems to end up in this function in defined in main.c:

void vAssertCalled( void )
{
    volatile unsigned long looping = 0;
    taskENTER_CRITICAL();
    {
        /* Use the debugger to set ul to a non-zero value in order to step out
                of this function to determine why it was called. */
        while( looping == 0LU )
        {
            portNOP();
        }
    }
    taskEXIT_CRITICAL();
}

After changing the while loop check to be
while( looping == 1LU )
the program seems to continue, the ARP response is received and a message is received on the echo server.
I’m not sure exactly what is causing this but I suspect it has something to do with task priorities.
vAssertCalled is called after a call to taskENTER_CRITICAL(); inside xQueueSemaphoreTake. I’d like to understand better for future reference.

Please provide a link to the assert that is failing. Here is an example of how to link to a line in github: https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/V10.4.6/queue.c#L1507 - as you see from the URL, that is linking to line 1507, which is an assert in xQueueSemaphoreTake() - but it’s not inside a critical section.

Unfortunately as a new user I’m not allowed to post links. Apologies I think I was mistaken earlier, it is not being called from xQueueSemaphoreTake. After looking through the call stack configASSERT() is being called from FreeRTOS/FreeRTOS-Kernel/portable/GCC/ARM_CM3/port.c line 688.
ucCurrentPriority is set as 0.
It was called from vTaskNotifyGiveFromISR FreeRTOS/FreeRTOS-Kernel/tasks.c line 5157 which was in turn called from EthernetISR FreeRTOS/FreeRTOS-Plus-TCP/source/portable/NetworkInterface/MPS2_AN385/NetworkInterface.c line 208.
It seems to be a task priority issue.

In which case it sounds like you haven’t set the priority of the interrupt - it has to be less than or equal to whatever you set configMAX_SYSCALL_INTERRUPT_PRIORITY to. I think the code comments where the assert is will help - also this page https://freertos.org/RTOS-Cortex-M3-M4.html

It is however one of the demo applications supplied (and I have made no modifications other than relevant network configuration) so the interrupt priorities have already been defined in FreeRTOSConfig.h and FreeRTOSIPConfig.h. As I understand it these priorities wouldn’t change based on running on a different linux distro/version? No where in the readme is it mentioned. I have read through that document and tried to alter interrupt priorities to values I thought were reasonable with no luck.

I will see if we can replicate it here. It is possible the QEMU version may make a difference as the version used during testing implemented eight priority bits - which no real Cortex-M devices do - and if there were eight you would not hit that assert.