[quote user="Arya Ba"]Thank you very much for your response, interesting so it seems BCACHE_inv is a very dangerous function to call in a HWI or high priority SWI as it may lead to starvation and delay in the real time process[/quote]
I'm not sure if calling BCACHE APIs from HWI context is dangerous (it is OK to call them from HWI context). But, I suppose this disabling of interrupts should be taken into consideration when using the APIs. But, in general, one needs to be weary of doing too much in a HWI. As little as possible should be done in HWI context, and any API that may run a long time should be pushed out to SWI or TSK context (if possible).
[quote user="Arya Ba"]Is there anywhere that these details are documented ? We referred to the DSP/BIOS API, however, there was no mention of calling context constraints[/quote]
You may have missed it. There should be a chapter in the API Guide (spru403s.pdf) called "Function Callability and Error Tables". This table shows you the acceptable context in which each API can be called.
[quote user="Arya Ba"]At the moment we removed all calls to BCACHE_inv in our system and have disabled caching on those regions. Unfortunately, due to the size and complexity of our system we cannot meet our hard deadlines if we disable caching completely. Cache corruption sounds disturbing, what are some common causes ? How can we debug for it ?[/quote]
I saw a post that you made a while back. I'm wondering, how much processing are you doing in your HWI threads? Is it possible to move out any of that code/processing into a corresponding SWI thread?
For cache, in general, you need to make sure all of your alignments are correct. When you call invalidate, you must make sure the size you are invalidating is a multiple of the alignment size. Otherwise, you could invalidate past a cache boundary (invalidating data that is indeed valid). Or write back data that's incorrect.
I found a guide here that may be useful: TMS320C64x+ DSP Cache User's Guide