Race in xTaskGenericNotifyWait() when cache enabled

[aggarg (Gaurav Aggarwal)]

Thank you for explaining.

@posner

xMPUSettings->xRegion[ portNUM_CONFIGURABLE_REGIONS - 1 ].ulRegionBaseAddress = 0x0807E000;
xMPUSettings->xRegion[ portNUM_CONFIGURABLE_REGIONS - 1 ].ulRegionSize = portMPU_SIZE_512KB | portMPU_REGION_ENABLE;
xMPUSettings->xRegion[ portNUM_CONFIGURABLE_REGIONS - 1 ].ulRegionAttribute = portMPU_PRIV_RW_USER_RW_NOEXEC | portMPU_NORMAL_OINC_SHARED;

Do you intend to use 512KB or Bytes?

@posner

The MPU-Region RAM is the remaining memory. To align it with the rest while keeping it as big as possible it would result in
RAM : origin = 0x08020000
length = 0x20000

leaving 0x3E000 blank. Is this correct? Would you recommend to order the memory in descending order to use most of it?

I am not sure I follow this completely. Are you sayin that the region of size 0x20000 and address 0x08020000 does not cover last 0x3E000 bytes (and as a result those 0x3E000 bytes fall in region 0)? If so, that is okay.

Can you try disabling any caches you have and see if this fixes your problem?

[posner]

Oh, yes you are correct of course 512B.

@aggarg

I am not sure I follow this completely. Are you sayin that the region of size 0x20000 and address 0x08020000 does not cover last 0x3E000 bytes (and as a result those 0x3E000 bytes fall in region 0)? If so, that is okay.

Yes that would mean the addresses 0x08040000 till 0x0807DFFF would be in region 0. I have used the th manual spna120 for reference.

[aggarg (Gaurav Aggarwal)]

Did you try turning off cache?

[posner]

@posner

1. state

2. With cache disabled, it appears to work.

This thread is now a few days old. But yes, I started with that.

[aggarg (Gaurav Aggarwal)]

@posner

But yes, I started with that.

Apologies for missing that and thank you for clarifying.

One possible reason is that an MPU region setting is turning off cache during context switch while it has not been flushed. I have seen this once. Double check all the settings for all your MPU regions.

[Nikolay-Po (Nikolay Pokhilchenko)]

@posner

Yes, I also saw that taskYIELD_WITHIN_API() is called shortly after. Could that if clause in between take too much time and cause my Problems?

Not sure it is related to your problem. I had somewhat similar problem on different CPU architecture and with MPU disabled and no cache. The problem was a race condition between the pending of an interrupt to interrupt controller and subsequent code flow after portYIELD() call. You may look at this aspect.

xStreamBufferReceive(…, portMAX_DELAY) Task Moved to Suspended and Never Wakes on Data

I feel like a blind kitten. Have tried to add into xTaskGenericNotifyWait, just before taskYIELD_WITHIN_API() a trap (line 7781 of tasks.c): if( ( xShouldBlock == pdTRUE ) && ( xAlreadyYielded == pdFALSE ) ) { { //Debug ToDo: remove this TaskStatus_t CurrentTaskStatus; vTaskGetInfo(pxCurrentTCB, &CurrentTaskStatus, pdFALSE, eInvalid); if (CurrentTaskStatus.eCurrentState == eSuspended) { asm volatile ("NOP"); } …

It is possible that the problem is not a cache but just an interrupt controller latency.

[posner]

Thanks alot @Nikolay-Po .

I think that pushed me in the right direction. My line of thought based on your input:

Our portmacro.h (derived from the TI HalCoGen Cortex-R5 MPU port) defined portYIELD_WITHIN_API() as a write to SSIR1, i.e. it pends a normal IRQ:

#define portYIELD_WITHIN_API()  { portSYS_SSIR1_REG = portSYS_SSIR1_SSKEY; \
                                  __asm(" DSB "); __asm(" ISB "); }

That yield is asynchronous — it only takes effect when CPSR.I is clear. But the kernel does things like:

taskYIELD_WITHIN_API();   /* pends SSI IRQ */
taskENTER_CRITICAL();     /* masks IRQs a few instructions later */

so the requested switch never happened at the point where the kernel requires it, and the waiting task was left unscheduled → “lost” notification.

Fix: delete our definition and let the kernel default apply, i.e. portYIELD_WITHIN_API() → portYIELD() → SWI #0. An SWI is an exception, not an interrupt, so it cannot be deferred by CPSR.I and switches synchronously. The extra portYIELD_WITHIN_API() we had added to tasks.c is reverted. Confirmed stable, and it’s actually cheaper than the SSI path (no VIM round-trip, no flag clear).

[aggarg (Gaurav Aggarwal)]

Thank you @posner for sharing your solution!