bank conflict DM6437 + imglib

Looking at the IMGLIB document SPRUF30 it seems the only function that has bank requirements is IMG_boundary_8, all the other functions say that there are no bank conflicts. If you want to avoid bank conflicts you just have to ensure that the data you are working with is aligned properly, assuming we are talking about L1D memory here, section 3.5.1 of SPRU871 discusses the L1D banking, essentially bits 4:2 of the address determine which bank to be used so your two buffers would have to start at locations that do not share the same 4:2 address bits. You can ensure that this happens by using the C compiler's pragma directives, in particular there is a DATA_MEM_BANK pragma discussed in section 6.8.3 of SPRU187.

Hi Bernie,

My problem is continuing...

Im not  right that my problem is about BANK conflict.

Allways my programm stops in .62 file like HWI_NMI, HWI_INT4, HWI_INT5, HWI_INT6, HWI_INT7... (alternately)

I don't know what could be!

Have something that I can verify?

When your code falls in one of these HWI_INT sections an interrupt has occurred and your code has branched to the interrupt vector; however, by default DSP/BIOS assigns most interrupts to a function called _HWI_UNUSED. This function is basically an infinite loop used to capture these stray events.

I would first check to see if these interrupts have been enabled in the IER register. Secondly, I would look at the DSP/BIOS HWI Manager (inside the .tcf file) and see which interrupt sources all of these events. If you are not intentionally using these interrupt sources then the IER bit for that interrupt should remain disabled.  

I don't know why, but it happen only when I enable the functions "IMG_thr_gt2max_8_cn" and "IMG_thr_le2min_8_cn" (IMGLIB functions).

If I disable (coment theses lines) it not happen.

I see the IER and the .tcf file, and I think that it is right.

Check the pointers that you are passing to the function. Make sure they point to valid memory region and are initialized correctly. Look at the cols/rows parameters to make sure they have the right value. Ensure the 'special requirements' for the kernel are followed. Look at the user's guide for the requirements.

By the way, you are calling the natural C version of the kernel (note the _cn suffix). This is good for debugging but is not the optimal implementation of the kernel. The optimal implementation has the same name but doesn't have the _cn suffix.

I took care about this advices but not work.

I took out the functions of IMGLIB from my code but the problem continue.

In the place of functions IMGLIB I put some others functions built for myself. But, I think that when the code reach until some quantity it fail, and when I comment some function it work again.

Would be something wrong in DSP.BIOS ?

For a situation like this my first thought would be to try increasing your stack size and possibly your heap size, if you have an overflow condition it could explain how the system tends to break depending on which and how many functions you have enabled. You can adjust these settings from within your BIOS configuration, if you open up System and right click on MEM - Memory Section Manager and go to properties, the general tab should have an entry for the stack size, you could increase this value and than rebuild and see if it has an effect on your project's stability.

Hi, I'm sorry about didn't have reply before.

So, I try to increase the stack size but it doesn't worked.

So, like I was losing to much time in this problem I restarted fron init (Building a new DSP/BIOS and so on), and now is working.

Don't ask me what was wrong, because I don't know!!!

Thank you for all.