Race in xTaskGenericNotifyWait() when cache enabled

Thank you for explaining.

Do you intend to use 512KB or Bytes?

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?

Oh, yes you are correct of course 512B.

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

Did you try turning off cache?

This thread is now a few days old. 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.

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.

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